[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse

While that is indeed the structure that we currently work with, I'm attracted
to the naming scheme used by eclipse that David has outlined.

David outlined what Geronimo does. I outlined what Eclipse does. You seem to be going with the former in this message.


Note that I have put orbit in the group name, as this indicates a jar
audited and redistributed from eclipse - as opposed to one generated by

For auditing/redistribution purposes that is why we sign the bundle with an eclipse.org certificate. Naming conventions are a good indicator but don't prove anything.

WRT the Orbit bundles, I don't remember the current state but at one point we talked about not conditioning/packing them so that the bytecodes were not altered. If that were true then the JAR shipped from Orbit would really be the orginal with some tweaks to the manifest.mf and signage. If the originator started shipping usable bundles then orbit would happily stop doing any work and reship the originator's bundle.

Using the orbit group name is an interesting approach if used in isolation. That is, if the group name does not impact the BSN then it is simply a repo structuring mechanism. Otherwise you end up with Maven repo conventions driving OSGi component structures. A leaky abstraction.

  I've not put eclipse- on the front of the artefact name
because I think there will be ample indication of the jars source (the
directory it is in, the MANIFEST.MF and the META-INF/pom.xml will all
record groupId and/or bundle id).

Currently the bundle name we put into the mortbay servlet api is


but if we apply the "rules" suggested by david, it should be:


This is a good bundle name (in my non-OSGi experienced eyes), as it identifies
both where it came from and what it is.

IMHO it is bad form to have the version number in the bundle name. That's why there is a separate bundle version header in the manifest.

For specification APIs at least, the geronimo artefacts have become
(or are becoming), the defacto canonical source of jars.  They are the
only organization that has systematically and consistently made these
jars available (see http://repo2.maven.org/maven2/org/apache/geronimo/specs/)
We could do worse than follow their model.

Of course we need to extend this model to encompass jars other than
specfications, but the model works equally for


would become


We need to be very clear. This is not at all the eclipse convention and will lead to some level of conflict and confusion. I am NOT saying it is wrong but AM saying that a broader discussion will be needed. The conflict I mentioned earlier is obvious here. Orbit already ships commons logging and it has the following characteristics.
bundle name = org.apache.commons.logging
version number = 1.1.1.v200904062255 (perhaps there is a later one now but you get the idea).
file name = org.apache.commons.logging_1.1.1.v200904062255.jar
This is typical of the pattern used throughout Orbit, Eclipse and all the people writing plugins/bundles for Eclipse.

Whatever scheme is selected to put things in Maven should work for all Eclipse things (not just special cases) and likely cannot expect that thousands of bundles be renamed (either their BSN or their file name).

That is the challenge here.