Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within e

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

> 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.

> http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0.jar
> http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0-javadoc.jar
> http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0-sources.jar
>
> 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
> eclipse.

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
>
>  org.mortbay.jetty.servlet-api
>
> but if we apply the "rules" suggested by david, it should be:
>
>  org.eclipse.orbit.servlet_2.5_spec
>
> 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
>
> http://repo2.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
>
> would become
>
> http://maven2.eclipse.org/org/eclipse/orbit/commons-logging/1.1.1/commons-logging-1.1.1.jar

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.

Jeff