You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by David Jencks <da...@yahoo.com> on 2009/05/09 19:39:06 UTC
Geronimo Spec jar naming/versioning
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Fwd: Geronimo Spec jar naming/versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Forgot to reply to dev@
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Sun, May 10, 2009 at 08:08
Subject: Re: Geronimo Spec jar naming/versioning
To: users@felix.apache.org
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.
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>
On Sun, May 10, 2009 at 03:08, David Jencks <da...@yahoo.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Fwd: Geronimo Spec jar naming/versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Forgot to reply to dev@
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Sun, May 10, 2009 at 08:08
Subject: Re: Geronimo Spec jar naming/versioning
To: users@felix.apache.org
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.
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>
On Sun, May 10, 2009 at 03:08, David Jencks <da...@yahoo.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Help needed with maven-bundle-plugin (was: Re: Geronimo Spec jar
naming/versioning)
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/5/14 David Jencks <da...@yahoo.com>
> Since no one has responded and the bundle plugin appears to claim there is
> some unspecified way to specify a version for the contents of the bundle I
> should file a bug?
>
apologies - I was off sick at the start of this week, and have since been
very busy on other work that pays my bills ;)
I'll respond to your original email after I've grabbed a coffee (it's ~2am
here) ... but I don't believe there's a bug
thanks
> david jencks
>
>
> On May 10, 2009, at 9:40 AM, David Jencks wrote:
>
> Lets start over.
>>
>> I'd like an way to get a package version for the packages in a bundle into
>> the Export-Packages and Import-Packages when using the maven-bundle-plugin
>> 2.0.0 or later, preferably without writing out these entries in the plugin
>> configuration. Also, the behavior of this plugin appears to have changed
>> radically between 1.4.3 and 2.0.0 and configurations that used to produce
>> reasonable results now produce nonsense.
>>
>> I'll only show the manifest entries of interest to save space.
>>
>> First, supplying no configuration produces reasonable results that only
>> lack the version for the packages in the bundle:
>>
>> configuration:
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <version>2.0.0</version>
>> <extensions>true</extensions>
>> <configuration>
>> <instructions>
>> </instructions>
>> </configuration>
>> </plugin>
>>
>>
>> manifest entries;
>> 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"
>> Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http;
>> version="2.5",javax.xml.namespace,org.w3c.dom
>>
>> What I'd like is some way to specify the version of the javax.portlet and
>> javax.portlet.filter packages in the Export-Package and Import-Package
>> headers without altering the uses clauses in the Export-Package header.
>>
>> I imagine the result would look something like this:
>> 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"
>> 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
>>
>> ----------------------------------------------------
>> I tried copying the configuration style used in the geronimo spec
>> bundles.
>>
>> configuration:
>> <properties>
>> <portals.osgi.import.pkg>*</portals.osgi.import.pkg>
>> <portals.osgi.export.pkg>*</portals.osgi.export.pkg>
>> <portals.osgi.private.pkg/>
>>
>> <portals.osgi.export>!META-INF*,${portals.osgi.export.pkg}*;version=${portals.osgi.export.version}</portals.osgi.export>
>> <portals.osgi.export.version>2.0</portals.osgi.export.version>
>>
>> <portals.osgi.import>!META-INF*,${portals.osgi.import.pkg}</portals.osgi.import>
>> <portals.osgi.symbolic.name>${groupId}.${artifactId}</
>> portals.osgi.symbolic.name>
>> <bnd.version.policy>$(version;==;$(@))</bnd.version.policy>
>> </properties>
>> ...
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <version>2.0.0</version>
>> <extensions>true</extensions>
>> <configuration>
>> <instructions>
>> <Export-Package>${portals.osgi.export}</Export-Package>
>> <Import-Package>${portals.osgi.import}</Import-Package>
>> <Private-Package>${portals.osgi.private.pkg}</Private-Package>
>> <_versionpolicy>${bnd.version.policy}</_versionpolicy>
>> </instructions>
>> </configuration>
>> </plugin>
>>
>> manifest entries:
>> 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
>>
>> There are several problems with this that I can see:
>> - too many imports
>> - exports include all imports, not just stuff in the bundle itself
>> - version 2.0 is applied to all exports, even the imports that are
>> imported with a different version.
>>
>>
>> If I go back to 1.4.3 I get more reasonable results:
>>
>> configuration:
>> same as above except using plugin v. 1.4.3
>>
>> manifest entries:
>>
>> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>> javax.servlet.http,javax.xml.namespace";version="2.0",javax.portlet;u
>> ses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";version="2.
>> 0"
>> Import-Package: javax.portlet;version="2.0",javax.portlet.filter;versi
>> on="2.0",javax.servlet.http,javax.xml.namespace,org.w3c.dom
>>
>> The only problem I see here is that the import of the servlet package
>> doesn't have a version.
>>
>> ---------------------------------------------------------------
>>
>> Just in case anyone reads this far, I reiterate: my goal is to specify the
>> version of the packages in the current bundle and have this show up in the
>> Export-Packages and Import-Packages headers, something like this:
>>
>> 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"
>> 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
>>
>> Do I have to write out these headers in their entirety in the plugin
>> configuration or is there some way to simply add the version to the
>> automatically generated headers?
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Help needed with maven-bundle-plugin (was: Re: Geronimo Spec jar naming/versioning)
Posted by David Jencks <da...@yahoo.com>.
Since no one has responded and the bundle plugin appears to claim
there is some unspecified way to specify a version for the contents of
the bundle I should file a bug?
thanks
david jencks
On May 10, 2009, at 9:40 AM, David Jencks wrote:
> Lets start over.
>
> I'd like an way to get a package version for the packages in a
> bundle into the Export-Packages and Import-Packages when using the
> maven-bundle-plugin 2.0.0 or later, preferably without writing out
> these entries in the plugin configuration. Also, the behavior of
> this plugin appears to have changed radically between 1.4.3 and
> 2.0.0 and configurations that used to produce reasonable results now
> produce nonsense.
>
> I'll only show the manifest entries of interest to save space.
>
> First, supplying no configuration produces reasonable results that
> only lack the version for the packages in the bundle:
>
> configuration:
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.0.0</version>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> </instructions>
> </configuration>
> </plugin>
>
>
> manifest entries;
> 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"
> Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http;
> version="2.5",javax.xml.namespace,org.w3c.dom
>
> What I'd like is some way to specify the version of the
> javax.portlet and javax.portlet.filter packages in the Export-
> Package and Import-Package headers without altering the uses clauses
> in the Export-Package header.
>
> I imagine the result would look something like this:
> 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"
> 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
>
> ----------------------------------------------------
> I tried copying the configuration style used in the geronimo spec
> bundles.
>
> configuration:
> <properties>
> <portals.osgi.import.pkg>*</portals.osgi.import.pkg>
> <portals.osgi.export.pkg>*</portals.osgi.export.pkg>
> <portals.osgi.private.pkg/>
> <portals.osgi.export>!META-INF*,$
> {portals.osgi.export.pkg}*;version=${portals.osgi.export.version}</
> portals.osgi.export>
> <portals.osgi.export.version>2.0</portals.osgi.export.version>
> <portals.osgi.import>!META-INF*,${portals.osgi.import.pkg}</
> portals.osgi.import>
> <portals.osgi.symbolic.name>${groupId}.${artifactId}</
> portals.osgi.symbolic.name>
> <bnd.version.policy>$(version;==;$(@))</bnd.version.policy>
> </properties>
> ...
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.0.0</version>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <Export-Package>${portals.osgi.export}</Export-Package>
> <Import-Package>${portals.osgi.import}</Import-Package>
> <Private-Package>${portals.osgi.private.pkg}</Private-
> Package>
> <_versionpolicy>${bnd.version.policy}</_versionpolicy>
> </instructions>
> </configuration>
> </plugin>
>
> manifest entries:
> 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
>
> There are several problems with this that I can see:
> - too many imports
> - exports include all imports, not just stuff in the bundle itself
> - version 2.0 is applied to all exports, even the imports that are
> imported with a different version.
>
>
> If I go back to 1.4.3 I get more reasonable results:
>
> configuration:
> same as above except using plugin v. 1.4.3
>
> manifest entries:
>
> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
> javax.servlet.http,javax.xml.namespace";version="2.0",javax.portlet;u
> ses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";version="2.
> 0"
> Import-Package: javax.portlet;version="2.0",javax.portlet.filter;versi
> on="2.0",javax.servlet.http,javax.xml.namespace,org.w3c.dom
>
> The only problem I see here is that the import of the servlet
> package doesn't have a version.
>
> ---------------------------------------------------------------
>
> Just in case anyone reads this far, I reiterate: my goal is to
> specify the version of the packages in the current bundle and have
> this show up in the Export-Packages and Import-Packages headers,
> something like this:
>
> 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"
> 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
>
> Do I have to write out these headers in their entirety in the plugin
> configuration or is there some way to simply add the version to the
> automatically generated headers?
>
> thanks
> david jencks
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help needed with maven-bundle-plugin (was: Re: Geronimo Spec jar
naming/versioning)
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/5/11 David Jencks <da...@yahoo.com>
> Lets start over.
>
> I'd like an way to get a package version for the packages in a bundle into
> the Export-Packages and Import-Packages when using the maven-bundle-plugin
> 2.0.0 or later, preferably without writing out these entries in the plugin
> configuration. Also, the behavior of this plugin appears to have changed
> radically between 1.4.3 and 2.0.0 and configurations that used to produce
> reasonable results now produce nonsense.
>
Hi David,
the "nonsense" results only occur when people have relied on unspec'd
behaviour in earlier versions,
namely that "provided" scope dependencies are not on the project classpath
passed to the BND tool.
(this behaviour was not intended and was a side-effect of a Maven setting
used by the bundleplugin)
some projects mis-used this behaviour and put
<Export-Package>*</Export-Package> in their poms
as a simple way to include and export all the packages in the project - any
build dependencies they
didn't want in the final bundle they then marked as "provided" scope
in the 2.0.0 release there was a conscious decision (discussed on this list)
to change this behaviour
so that the complete compilation classpath would be passed to the BND tool -
the reason for this was
because omitting dependencies from the classpath meant that BND didn't have
the complete picture
and could not then augment imports with the right dependency versions.
this is covered in the FAQ:
http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhydoIseemoreclassesinmybundleafterupgradingtomavenbundleplugin2.0.0
?
and is the reason why we bumped the major version up to 2
I'll only show the manifest entries of interest to save space.
>
> First, supplying no configuration produces reasonable results that only
> lack the version for the packages in the bundle:
>
> configuration:
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.0.0</version>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> </instructions>
> </configuration>
> </plugin>
>
correct - version 2.0.0 detects packages in the local sources and configures
the bundleplugin accordingly.
we yet don't check for the specification version in the manifest config /
source, but this would be possible
- if you'd like automatic versioning of local packages please open a feature
request (not a bug) on JIRA
> manifest entries;
> 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"
> Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http;
> version="2.5",javax.xml.namespace,org.w3c.dom
>
> What I'd like is some way to specify the version of the javax.portlet and
> javax.portlet.filter packages in the Export-Package and Import-Package
> headers without altering the uses clauses in the Export-Package header.
>
> I imagine the result would look something like this:
> 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"
> 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
>
> ----------------------------------------------------
> I tried copying the configuration style used in the geronimo spec bundles.
>
> configuration:
> <properties>
> <portals.osgi.import.pkg>*</portals.osgi.import.pkg>
> <portals.osgi.export.pkg>*</portals.osgi.export.pkg>
^ this is an example of using "*" to include and export everything on the
classpath passed to BND
if you want to get the same behaviour in 2.0.0 while using "*" then add this
configuration setting:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<excludeDependencies>*;scope=provided|runtime</excludeDependencies>
</configuration>
</plugin>
which should remove the bogus entries by hiding provided and runtime
dependencies from BND
the alternative is to be more explicit in your instructions:
<Export-Package>javax.portlet.*;version=${portals.osgi.export.version}</Export-Package>
which tells BND to export all packages under javax.portlet using the given
version
<portals.osgi.private.pkg/>
>
> <portals.osgi.export>!META-INF*,${portals.osgi.export.pkg}*;version=${portals.osgi.export.version}</portals.osgi.export>
> <portals.osgi.export.version>2.0</portals.osgi.export.version>
>
> <portals.osgi.import>!META-INF*,${portals.osgi.import.pkg}</portals.osgi.import>
> <portals.osgi.symbolic.name>${groupId}.${artifactId}</
> portals.osgi.symbolic.name>
> <bnd.version.policy>$(version;==;$(@))</bnd.version.policy>
> </properties>
> ...
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.0.0</version>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <Export-Package>${portals.osgi.export}</Export-Package>
> <Import-Package>${portals.osgi.import}</Import-Package>
> <Private-Package>${portals.osgi.private.pkg}</Private-Package>
> <_versionpolicy>${bnd.version.policy}</_versionpolicy>
> </instructions>
> </configuration>
> </plugin>
>
> manifest entries:
> 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
>
> There are several problems with this that I can see:
> - too many imports
note that the default is to import whatever is exported (not just packages
from other bundles)
http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages
?
> - exports include all imports, not just stuff in the bundle itself
actually you'll probably find that all exported packages are in the bundle
(use "jar tvf ...")
because BND doesn't just zip up "target/classes" like the jar-plugin,
instead it pulls files
from the entire classpath according to your instructions
> - version 2.0 is applied to all exports, even the imports that are imported
> with a different version.
>
correct, because with this setup all dependencies are passed to BND so it
can detect
the dependency version and apply this to imported packages - however,
because you
are using "*;version=2.0" to export, then all packages will be sucked into
the bundle
and then explicitly exported as version 2.0 (as you requested in your
instructions)
If I go back to 1.4.3 I get more reasonable results:
>
> configuration:
> same as above except using plugin v. 1.4.3
>
> manifest entries:
>
> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
> javax.servlet.http,javax.xml.namespace";version="2.0",javax.portlet;u
> ses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";version="2.
> 0"
> Import-Package: javax.portlet;version="2.0",javax.portlet.filter;versi
> on="2.0",javax.servlet.http,javax.xml.namespace,org.w3c.dom
>
> The only problem I see here is that the import of the servlet package
> doesn't have a version.
>
these imports don't have a version because they come from provided
dependencies,
which aren't passed to BND in version 1.4.3 - this is exactly why we changed
it round
that the complete classpath is sent to BND, then your imports get the
correct versions
executive summary:
1) don't export * unless you really want everything in your bundle
2) use something like my.specific.domain.*;version="my.version"
3) consider using <_versionpolicy> to add automatic import ranges
remember to raise a feature request if you want automatic versioning of
local source ;)
HTH
---------------------------------------------------------------
>
> Just in case anyone reads this far, I reiterate: my goal is to specify the
> version of the packages in the current bundle and have this show up in the
> Export-Packages and Import-Packages headers, something like this:
>
> 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"
> 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
>
> Do I have to write out these headers in their entirety in the plugin
> configuration or is there some way to simply add the version to the
> automatically generated headers?
>
> thanks
> david jencks
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Help needed with maven-bundle-plugin (was: Re: Geronimo Spec jar naming/versioning)
Posted by David Jencks <da...@yahoo.com>.
Lets start over.
I'd like an way to get a package version for the packages in a bundle
into the Export-Packages and Import-Packages when using the maven-
bundle-plugin 2.0.0 or later, preferably without writing out these
entries in the plugin configuration. Also, the behavior of this
plugin appears to have changed radically between 1.4.3 and 2.0.0 and
configurations that used to produce reasonable results now produce
nonsense.
I'll only show the manifest entries of interest to save space.
First, supplying no configuration produces reasonable results that
only lack the version for the packages in the bundle:
configuration:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.0.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
</instructions>
</configuration>
</plugin>
manifest entries;
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"
Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http;
version="2.5",javax.xml.namespace,org.w3c.dom
What I'd like is some way to specify the version of the javax.portlet
and javax.portlet.filter packages in the Export-Package and Import-
Package headers without altering the uses clauses in the Export-
Package header.
I imagine the result would look something like this:
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"
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
----------------------------------------------------
I tried copying the configuration style used in the geronimo spec
bundles.
configuration:
<properties>
<portals.osgi.import.pkg>*</portals.osgi.import.pkg>
<portals.osgi.export.pkg>*</portals.osgi.export.pkg>
<portals.osgi.private.pkg/>
<portals.osgi.export>!META-INF*,$
{portals.osgi.export.pkg}*;version=${portals.osgi.export.version}</
portals.osgi.export>
<portals.osgi.export.version>2.0</portals.osgi.export.version>
<portals.osgi.import>!META-INF*,${portals.osgi.import.pkg}</
portals.osgi.import>
<portals.osgi.symbolic.name>${groupId}.${artifactId}</
portals.osgi.symbolic.name>
<bnd.version.policy>$(version;==;$(@))</bnd.version.policy>
</properties>
...
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.0.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>${portals.osgi.export}</Export-Package>
<Import-Package>${portals.osgi.import}</Import-Package>
<Private-Package>${portals.osgi.private.pkg}</Private-
Package>
<_versionpolicy>${bnd.version.policy}</_versionpolicy>
</instructions>
</configuration>
</plugin>
manifest entries:
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
There are several problems with this that I can see:
- too many imports
- exports include all imports, not just stuff in the bundle itself
- version 2.0 is applied to all exports, even the imports that are
imported with a different version.
If I go back to 1.4.3 I get more reasonable results:
configuration:
same as above except using plugin v. 1.4.3
manifest entries:
Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
javax.servlet.http,javax.xml.namespace";version="2.0",javax.portlet;u
ses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";version="2.
0"
Import-Package: javax.portlet;version="2.0",javax.portlet.filter;versi
on="2.0",javax.servlet.http,javax.xml.namespace,org.w3c.dom
The only problem I see here is that the import of the servlet package
doesn't have a version.
---------------------------------------------------------------
Just in case anyone reads this far, I reiterate: my goal is to specify
the version of the packages in the current bundle and have this show
up in the Export-Packages and Import-Packages headers, something like
this:
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"
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
Do I have to write out these headers in their entirety in the plugin
configuration or is there some way to simply add the version to the
automatically generated headers?
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Geronimo Spec jar naming/versioning
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/5/10 David Jencks <da...@yahoo.com>
firstly I just wanted to note that in OSGi bundles can be versioned
independently of packages,
just because a bundle has one version doesn't mean its exports have to use
the same version
ideally these spec jars should export their packages with the spec version,
and also import the
same packages (for substitutability reasons) with ranges that match
compatible releases - this
may mean using a singleton range like "[2.5]" if even a small change is
consider incompatible
you can tell BND which import version policy to use:
http://aqute.biz/Code/Bnd#versionpolicy
which can save you from maintaining lots of ranges
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.
>
>
not quite - BND also picks up "packageinfo" resources which have the
property:
version <some-number>
but these files only appear in OSGi jars like the core and compendium
artifacts
(at least I haven't seen any other jars contain "packageinfo" resource
bundles)
I don't know if this is related to "package-info.java" files, but Peter
should know ;)
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.
>
presumably you already have an export instruction in your pom, so you can
add versions there:
Export-Package: org.foo.*;version="2", org.bar.*;version="1"
similarly you can do the same for your imports, you can even add ranges:
Import-Package: org.wibble;version="[1, 2)", *
(the trailing wildcard is there so BND adds any necessary imports
accidentally missed off the list)
you can also use the "versionpolicy" instruction to help automate some of
the range settings
> The bundle I'm working on is portlet api 2.0. Doing nothing results in no
> versions
>
that is the default - at least if BND can't find any version, it doesn't
second-guess
> , 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.
hmm, could you point to the pom instructions used to generate this manifest?
( having different versions for the same package in exports / imports makes
me
suspect that the pom instructions are explicitly setting these different
versions )
> 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.
>
nothing strange ;) this instruction tells BND to remove the named headers
from the manifest
so if you ask it to remove the Private-Package header, that entry won't
appear in the final manifest
( as Guillaume said Private-Package is an informational header for BND, it
is not an OSGi header )
> thanks
> david jencks
>
>
>> On Sun, May 10, 2009 at 03:08, David Jencks <da...@yahoo.com>
>> 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
>>>
>>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers, Stuart
Re: Geronimo Spec jar naming/versioning
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com>
> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Geronimo Spec jar naming/versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
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.
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>
On Sun, May 10, 2009 at 03:08, David Jencks <da...@yahoo.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Geronimo Spec jar naming/versioning
Posted by David Jencks <da...@yahoo.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Geronimo Spec jar naming/versioning
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>
Re: Geronimo Spec jar naming/versioning
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>