What is Orbit?

Orbit is a project designed to be a repository for third party libraries that are approved for use in Eclipse projects. If the incoming libraries are not already bundles then Orbit committers will work to create a bundle that is suitable for use in Eclipse projects.

Does Orbit replace or affect the Eclipse Foundation legal process?

NO! Orbit holds only libraries that have been approved by the standard legal process. Projects must still follow this process to request permission to use libraries in their releases.

If a library is approved for use in "all" projects, do I still have to go through the legal process?

As of this writing, all projects must request permission to use any third party libraries. More generally, this is a question for the legal team. Orbit does not affect the IP policy and legal process.

Do projects have to use the Orbit bundles?

This is not explicitly required however we do hope that the Release Review process is enhanced to require justification for using a library in your release and not using the corresponding bundle from Orbit. There may well be valid scenarios here the Orbit bundle is not appropriate but projects are strongly urged to share as much as possible.

What if I don't want to put the library I need into Orbit?

That's fine but you will be foregoing the help and support you would get of the greater Orbit community as well as preventing others from sharing in your efforts. Keep in mind that you may have to justify this approach when it comes time for your release review.

Who are the committers in Orbit?

The following is the current list of committers and the projects they represent. Note that those with ?? after their names are potential committers.

How do I become a committer in Orbit?

Orbit committers are already committers from other Eclipse projects that have a need for a third party library. These people come to Orbit with an approved library and propose to include it in Orbit. If they are not already a committer in Orbit and their project does not have any committers in Orbit, they can become a committer by agreeing to bundle and maintain the new library. Accordingly, they will then be responsible for the care and feeding of that library and the corresponding bundle. You should make your interest known on the Orbit mailing list.

How do you name bundles containing other people's code?

That's a great question! See the documentation and guidelines on Bundle Naming.

Which libraries are managed in Orbit

The complete list is of bundles available from Orbit is on the Orbit download page. As the project is just getting underway, we don't have a downloads page so here is a list of the bundles that will be included in Orbit.

Library

Bundle

Version

Ant

org.apache.ant

1.6.5

Axis

org.apache.axis

1.3.0

Batik

org.apache.batik

1.6.0

Batik PDF

org.apache.batik.pdf

1.0 beta2

Cactus

org.apache.cactus

1.7.2

Codec

org.apache.commons.codec

1.2.0

Commons Logging

org.apache.commons_.logging

1.0.4

Commons Net

org.apache.commons.net

1.4.1

CSS

org.w3c.css.sac

1.3.0

Derby

org.apache.derby

10.1.2.1

ICU4J

com.ibm.icu

3.4.4.1

Jakarta ORO

org.apache.oro

2.0.8

Jasper Compiler

org.apache.jasper.compiler

5.5.17

Jasper Runtime

org.apache.jasper.runtime

5.5.17

Jetty

org.mortbay.jetty

5.1.11

JMX APIs

javax.management

??

JMX Remote APIs

javax.management.remote

??

Junit

org.junit

3.8.1

Junit 4

org.junit4

4.1.0

Log4j

org.apache.jakarta_log4j

1.2.8

Lucene

org.apache.lucene

1.4.3

MX4J

net.sourceforge.mx4j

3.0.1

MX4J Remote

net.sourceforge.mx4j.remote

3.0.1

OSGi services API

org.eclipse.osgi.services

3.1.100

Rhino

org.mozilla.rhino

1.6.0

Servlet API

javax.servlet

2.3, 2.4

Servlet JSP API

javax.servlet.jsp

1.2, 2.0

SSH

com.jcraft.jsch

0.1.28

UDDI4J

org.uddi4j

2.0.4

WSDL4J

org.wsdl4j

1.4.0

WSIL4J

org.apache.wsil4j

1.0.0

Xerces

org.apache.xerces

2.8.0

XML Pull

org.xmlpull.v1

??

XML RPC

org.apache.xmlrpc

3.0.0

How does Orbit manage multiple versions of the same library?

Luckily OSGi supports multiple versions of the same bundle installed and running at the same time so this does not present any particular runtime problems. At development time however there is a challenge of project naming. Since the Eclipse convention has been to use the bundle symbolic name as the name of the project, there would be a conflict if two versions of the same project need to be in the workspace at the same time.

The initial direction here is to use a CVS branch for each version of a library. So, for example, for javax.servlet there is version 2.3 and 2.4 of the library. Correspondingly, there branches named v2_3 and v2_4 are created to hold the related content. HEAD of the javax.servlet project is empty except for a readme.txt file indicating that all work is carried out in branches.

How do I add something to Orbit?

There are a number of factors and processes to be considered when adding a library to Orbit. Please see Adding Bundles To Orbit.

How is source managed/delivered?

TBD

How do I work with a bundle in Orbit?

Since all of the interesting orbit work is done in branches, working with an orbited bundle can be confusing to the first-time user. But just follow these simple steps and you'll have it checked out into your workspace in no time!

Create a repository connection to the orbit repository.

Navigate to HEAD/org.eclipse.orbit/<your_project>.

Check your project out into your workspace.

Note that the project will be empty. (this is ok)

In the Navigator (or Package Explorer, etc) right-click on the project and choose Replace With -> Another Branch or Version... and select the branch that you want to work with. (the branch names are the versions)

Should we use qualifiers in the bundle version?

Yes. We should add a qualifier as the 4th part of a bundle version. e.g. 3.8.1.qualifier.

If we have versions which already have 4 parts to them then we should pad the 4th segment to 2 digits. For instance: 4.1.0.01_qualifier.