On May 9, 2009, at 11:08 PM, Guillaume Nodet wrote:

The package version are discovered by reading the OSGi manifest
headers of the maven dependencies.
If the dependencies are not OSGi bundles, no infos will be found. This
is the case for all packages provided by the JRE.
In addition, I don't think there is any clear specification of those
package versions, as some system bundles may export those packages
with different versions: for example all packages could be exported
with a version of 1.5 when running JDK 5, or 1.6 when running under
JDK 6.
Adding some versions infos on the org.w3c.dom package would limit its
use I think.

At this point I don't have a strong opinion about package versions for javax.xml.namespace or org.w3c.dom. I am interested in specifying the package version for the packages supplied in the current bundle in the Export-Package and Import-Package headers. I have not found a way to make that work with the 2.0.0 plugin. The bundle I'm working on is portlet api 2.0. Doing nothing results in no versions, using the kinds of specification you used for geronimo specs results in this:

Export-Package: javax.servlet;version="2.0",javax.portlet.filter;uses:
 ="javax.portlet,javax.xml.namespace,javax.servlet.http,org.w3c.dom";v
 ersion="2.0",javax.portlet;uses:="javax.xml.namespace,javax.servlet.h
 ttp,org.w3c.dom";version="2.0",javax.servlet.http;uses:="javax.servle
 t";version="2.0",javax.servlet.resources;version="2.0"

Import-Package: javax.portlet;version="2.0",javax.portlet.filter;versi
 on="2.0",javax.servlet;version="2.5",javax.servlet.http;version="2.5"
 ,javax.servlet.resources;version="2.5",javax.xml.namespace,org.w3c.do
 m

Note that the export list includes all the import packages that aren't in the bundle but with the wrong version.




The Private-Package header can be removed as it's not used by the OSGi
framework.  I think BND has a way to specify a special headers that
will contain a list of headers to be removed from the manifest.
Try with

  <_removeheaders>Private-Package<_removeheaders>

Strangely enough using a configuration like in the g. specs results in the Private-Package header disappearing.

thanks
david jencks


On Sun, May 10, 2009 at 03:08, David Jencks <[email protected]> wrote:
So upon more investigation I've discovered that there is apparently no relationship at all between Bundle-Version and the version of a package specified in Export-Package or Import-Package, so there doesn't seem to be
any need to change the geronimo spec naming convention to align them.

However the instructions for the maven-bundle-plugin 2.0.0 on specifying
this package version I'm finding less than clear:

Besides explicitly listing package version attributes, BND will also
determine package versions by examining the source JAR file or from
packageinfo files in the package directory.

I don't understand how this might be working. First of all, I can't figure out what the packageinfo file referred to is. There's a package- info.java and presumably one could specify a version in there with an annotation.... but what annotation? I assume the source jars referred to might be maven dependencies. The plugin seems to be extracting version info for imported
packages.

There's also some mention of specifying a version property directly to BND
but I haven't been able to figure out how to use it with the plugin.

To be more concrete, here are the manifest entries I'm getting now ( with no
maven-bundle-plugin configuration) :

Export-Package: javax.portlet.filter;uses:="javax.portlet,javax.xml.na mespace,javax.servlet.http,org.w3c.dom",javax.portlet;uses:="javax.xm
 l.namespace,javax.servlet.http,org.w3c.dom"
Private-Package: javax.portlet.filter,javax.portlet,
Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http;
 version="2.5",javax.xml.namespace,org.w3c.dom

and I think I'd like (with proper line lengths):

Export-Package: javax.portlet.filter;uses:="javax.portlet,javax.xml.na mespace ,javax .servlet .http,org.w3c.dom";version="2.0",javax.portlet;uses:="javax.xm
 l.namespace,javax.servlet.http,org.w3c.dom";version="2.0"
Private-Package:
Import-Package:
javax .portlet ;version="2.0",javax.portlet.filter;version="2.0",javax.servlet.http;
 version="2.5",javax.xml.namespace,org.w3c.dom


Is there some way to do this without completely writing down the import and export package strings, just supplying the version somehow to the plugin?

I guess having Private-Package be the same as Export-Package does no
particular harm but I personally find it a little weird, especially with the
final ",".

thanks
david jencks





On May 9, 2009, at 10:39 AM, David Jencks wrote:

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.)
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Import-Package: javax.servlet;version="2.5",javax.servlet.http;version
="2.5",javax.servlet.resources;version="2.5"
Bnd-LastModified: 1241886515459
Export-Package: javax.servlet.http;uses:="javax.servlet";version="2.5"
,javax.servlet;version="2.5",javax.servlet.resources;version="2.5"
Bundle-Version: 1.3.0.SNAPSHOT
Bundle-Name: geronimo-servlet_2.5_spec
Bundle-Description: Servlet 2.5 Specification
Bundle-DocURL: http://www.apache.org
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
ec
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
correct....

---------------------------

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
org.apache.geronimo.specs:geronimo-servlet_2.5_spec:2.5.4:jar

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

-----------------------------

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.


thanks
david jencks





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to