2009/5/10 David Jencks <[email protected]> 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 <[email protected]> >> wrote: >> >>> So upon more investigation I've discovered that there is apparently no >>> relationship at all between Bundle-Version and the version of a package >>> specified in Export-Package or Import-Package, so there doesn't seem to >>> be >>> any need to change the geronimo spec naming convention to align them. >>> >>> However the instructions for the maven-bundle-plugin 2.0.0 on specifying >>> this package version I'm finding less than clear: >>> >>> Besides explicitly listing package version attributes, BND will also >>> determine package versions by examining the source JAR file or from >>> packageinfo files in the package directory. >>> >>> I don't understand how this might be working. First of all, I can't >>> figure >>> out what the packageinfo file referred to is. There's a >>> package-info.java >>> and presumably one could specify a version in there with an >>> annotation.... >>> but what annotation? I assume the source jars referred to might be maven >>> dependencies. The plugin seems to be extracting version info for >>> imported >>> packages. >>> >>> There's also some mention of specifying a version property directly to >>> BND >>> but I haven't been able to figure out how to use it with the plugin. >>> >>> To be more concrete, here are the manifest entries I'm getting now ( with >>> no >>> maven-bundle-plugin configuration) : >>> >>> Export-Package: javax.portlet.filter;uses:="javax.portlet,javax.xml.na >>> mespace,javax.servlet.http,org.w3c.dom",javax.portlet;uses:="javax.xm >>> l.namespace,javax.servlet.http,org.w3c.dom" >>> Private-Package: javax.portlet.filter,javax.portlet, >>> Import-Package: javax.portlet,javax.portlet.filter,javax.servlet.http; >>> version="2.5",javax.xml.namespace,org.w3c.dom >>> >>> and I think I'd like (with proper line lengths): >>> >>> Export-Package: javax.portlet.filter;uses:="javax.portlet,javax.xml.na >>> >>> >>> mespace,javax.servlet.http,org.w3c.dom";version="2.0",javax.portlet;uses:="javax.xm >>> l.namespace,javax.servlet.http,org.w3c.dom";version="2.0" >>> Private-Package: >>> Import-Package: >>> >>> javax.portlet;version="2.0",javax.portlet.filter;version="2.0",javax.servlet.http; >>> version="2.5",javax.xml.namespace,org.w3c.dom >>> >>> >>> Is there some way to do this without completely writing down the import >>> and >>> export package strings, just supplying the version somehow to the plugin? >>> >>> I guess having Private-Package be the same as Export-Package does no >>> particular harm but I personally find it a little weird, especially with >>> the >>> final ",". >>> >>> thanks >>> david jencks >>> >>> On May 9, 2009, at 10:39 AM, David Jencks wrote: >>> >>> In Geronimo we long ago discovered that spec jars always contain errors >>>> and need new versions released. After a lot of discussion we adopted >>>> this >>>> convention for artifactId and version: >>>> >>>> artifactId: geronimo-<spec-name>_<spec-version>_spec >>>> version: 1.x[.y][-SNAPSHOT] >>>> >>>> So, the spec version is in the artifact Id and the version is entirely >>>> separate and unrelated. >>>> >>>> A while back Guillaume osgi-ified our specs using the felix >>>> maven-bundle-plugin and he seems happy with the results. However I >>>> think >>>> there are problems with it. Lets look at the servlet 2.5 spec manifest: >>>> >>>> Manifest-Version: 1.0 >>>> Created-By: 1.5.0_16 (Apple Inc.) >>>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt >>>> Import-Package: javax.servlet;version="2.5",javax.servlet.http;version >>>> ="2.5",javax.servlet.resources;version="2.5" >>>> Bnd-LastModified: 1241886515459 >>>> Export-Package: javax.servlet.http;uses:="javax.servlet";version="2.5" >>>> ,javax.servlet;version="2.5",javax.servlet.resources;version="2.5" >>>> Bundle-Version: 1.3.0.SNAPSHOT >>>> Bundle-Name: geronimo-servlet_2.5_spec >>>> Bundle-Description: Servlet 2.5 Specification >>>> Bundle-DocURL: http://www.apache.org >>>> Originally-Created-By: 1.5.0_13 (Apple Computer, Inc.) >>>> Bundle-Vendor: The Apache Software Foundation >>>> Bundle-ManifestVersion: 2 >>>> Implementation-Title: Apache Geronimo >>>> Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-servlet_2.5_sp >>>> ec >>>> Tool: Bnd-0.0.227 >>>> Implementation-Version: 1.3-SNAPSHOT >>>> >>>> Note that the exports and imports indicate javax.servlet;version="2.5" >>>> whereas the bundle-version is 1.3.0.SNAPSHOT. IIUC this means that the >>>> next >>>> version of this spec jar, 1.3.1, could not be imported into this bundle >>>> to >>>> supply the actual classes. Similarly any bundle needing the servlet 2.5 >>>> classes and specifying this in the import would not be able to get them >>>> from >>>> this bundle. >>>> >>>> I'd like to pause for a moment and ask the osgi experts if this is >>>> correct.... >>>> >>>> --------------------------- >>>> >>>> Assuming it is correct, I think we need to fix this. I think that we >>>> need >>>> to at least change the version of the geronimo spec jars to start with >>>> the >>>> x.y version of the spec involved. we then have 2 more bits of version >>>> to >>>> play with. At this point I think we only need to use one. So, the next >>>> release of this spec jar might be 2.5.4. We could presumably arrange >>>> things >>>> so that the import-packages specified 2.5 as now. I'm not sure if the >>>> export-package should then specify 2.5 or 2.5.4: advice would be great. >>>> >>>> One danger is if the spec committees suddenly decide to start using >>>> 3-segment spec numbers. I've seen stuff like 1.1 MR6 but I don't think >>>> these have affected the api exposed in the spec jars, although sometimes >>>> they might affect internal behavior slightly. >>>> >>>> At this point we'd have duplicate spec version info, as in >>>> org.apache.geronimo.specs:geronimo-servlet_2.5_spec:2.5.4:jar >>>> >>>> This suggests changing the artifactId as well. IIUC "best practice" is >>>> to >>>> have artifactId == base java package, here javax.servlet. How important >>>> is >>>> this convention considered? It seems that we could either use the base >>>> package name, relying on the groupId to distinguish from e.g. sun spec >>>> jars, >>>> or something like geronimo-servlet-spec. >>>> >>>> ----------------------------- >>>> >>>> At this point I think we should change the artifactId to the base java >>>> package and the version to start with the 2 segment spec version >>>> followed by >>>> a single geronimo version. >>>> >>>> thanks >>>> david jencks >>> >>> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Stuart
