geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Geronimo Spec jar naming/versioning
Date Sat, 09 May 2009 17:39:06 GMT
In Geronimo we long ago discovered that spec jars always contain  
errors and need new versions released.  After a lot of discussion we  
adopted this convention for artifactId and version:

artifactId:  geronimo-<spec-name>_<spec-version>_spec
version: 1.x[.y][-SNAPSHOT]

So, the spec version is in the artifact Id and the version is entirely  
separate and unrelated.

A while back Guillaume osgi-ified our specs using the felix maven- 
bundle-plugin and he seems happy with the results.  However I think  
there are problems with it.  Lets look at the servlet 2.5 spec manifest:

Manifest-Version: 1.0
Created-By: 1.5.0_16 (Apple Inc.)
Import-Package: javax.servlet;version="2.5",javax.servlet.http;version
Bnd-LastModified: 1241886515459
Export-Package: javax.servlet.http;uses:="javax.servlet";version="2.5"
Bundle-Version: 1.3.0.SNAPSHOT
Bundle-Name: geronimo-servlet_2.5_spec
Bundle-Description: Servlet 2.5 Specification
Originally-Created-By: 1.5.0_13 (Apple Computer, Inc.)
Bundle-Vendor: The Apache Software Foundation
Bundle-ManifestVersion: 2
Implementation-Title: Apache Geronimo
Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-servlet_2.5_sp
Tool: Bnd-0.0.227
Implementation-Version: 1.3-SNAPSHOT

Note that the exports and imports indicate javax.servlet;version="2.5"  
whereas the bundle-version is 1.3.0.SNAPSHOT.  IIUC this means that  
the next version of this spec jar, 1.3.1, could not be imported into  
this bundle to supply the actual classes.  Similarly any bundle  
needing the servlet 2.5 classes and specifying this in the import  
would not be able to get them from this bundle.

I'd like to pause for a moment and ask the osgi experts if this is  


Assuming it is correct, I think we need to fix this.  I think that we  
need to at least change the version of the geronimo spec jars to start  
with the x.y version of the spec involved.  we then have 2 more bits  
of version to play with.  At this point I think we only need to use  
one.  So, the next release of this spec jar might be 2.5.4.  We could  
presumably arrange things so that the import-packages specified 2.5 as  
now.  I'm not sure if the export-package should then specify 2.5 or  
2.5.4: advice would be great.

One danger is if the spec committees suddenly decide to start using 3- 
segment spec numbers.   I've seen stuff like 1.1 MR6 but I don't think  
these have affected the api exposed in the spec jars, although  
sometimes they might affect internal behavior slightly.

At this point we'd have duplicate spec version info, as in

This suggests changing the artifactId as well.  IIUC "best practice"  
is to have artifactId == base java package, here javax.servlet.  How  
important is this convention considered?  It seems that we could  
either use the base package name, relying on the groupId to  
distinguish from e.g. sun spec jars, or something like geronimo- 


At this point I think we should change the artifactId to the base java  
package and the version to start with the 2 segment spec version  
followed by a single geronimo version.

david jencks

View raw message