On 26 Jan 2012, at 10:56, Thomas GILLET wrote: > Hello Stuart, thanks for all the info. Unfortunately I cannot reproduce the > behaviors you are describing. > > Stuart McCulloch wrote: >> >> The behaviour for the "bundle:bundle" goal follows bnd by not using any >> version for exported packages unless you supply a version > > Well with versions 2.3.5 and 2.3.6, without any configuration (no > bundle:manifest goal), my non-versioned packages are all exported with the > bundle version.
You're right, and it turns out this was actually a change in bnd - the bundleplugin doesn't set any version on the export instruction passed to bnd (you can confirm this with "mvn -X package") The change was in bnd's Builder.java where it uses the bundle version as the default if the export package instruction does not have any version set: https://github.com/bndtools/bnd/commit/19612e8fcba2035e83bbe2639f5fb927d48fd709 The difference between this and setting the version explicitly is that it doesn't narrow the import range using the versionpolicy (whereas it does narrow it if you set the export package version) Apologies for any confusion > Stuart McCulloch wrote: >> >> You can make the "bundle:manifest" goal behave more like "bundle:bundle" >> by setting <rebuildBundle>true</rebuildBundle> >> [...] >> The bug where the "bundle:bundle" goal could pick up an existing manifest >> from the target directory and merge its headers into the final result >> [...] is fixed in 2.3.6. >> > > Again I tried with version 2.3.5 and 2.3.6, with and without the > "rebuildBundle" parameter, and there isn't any change: export always has a > version, import has a version only with the extra bundle:manifest goal. > Also is there an issue about the merging of an existing manifest ? I don't > find one. The change was: http://mail-archives.apache.org/mod_mbox/felix-commits/201110.mbox/%[email protected]%3E It's related to https://issues.apache.org/jira/browse/FELIX-3142 - but this change only covers the manifest in target/classes so the main issue is still open. But it turns out that this particular difference wrt. import versions is not related to the merging issue in the bundleplugin, because the Maven debug (-X) shows no merging is happening on the bundleplugin side. The difference is actually because bnd scans the project classpath for existing manifests so it can scrape them for versioning information, and target/classes is on the project classpath. You can confirm this by adding the following configuration setting: <configuration> <manifestLocation>target/classes/FOO</manifestLocation> <instructions> ... </instructions> </configuration> The bundle manifest will then be unpacked to target/classes/FOO/META-INF/MANIFEST.MF instead of target/classes/META-INF/MANIFEST.MF and will not be seen by bnd in the second execution. Note that the unpacking of the manifest to target/classes/META-INF/MANIFEST.MF is a convenience - the manifestLocation setting does not alter it's position in the actual bundle. So this behaviour is expected (because the target location wasn't cleaned between the two executions) - most people never encounter it because they use the bundle lifecycle rather than repeated executions inside the pom.xml, and in most cases it won't be an issue because it just means the import version is narrowed to match the bundle version. And if you explicitly set your export versions in the pom then you also won't encounter it. However it is an inconsistency, so feel free to open an issue (and provide a patch if you have time). > Meanwhile I discovered an other strange thing. If I add > <Export-Package>{local-packages};version=${project.version}</Export-Package> > in my instructions, the import statements for exported packages have always > the correct version, even without the bundle:manifest goal. > An other workaround for my original problem, but not very good because it > would override any packageinfo version (which I'm not using but still). This is expected - when you set the export version explicitly, bnd uses it to narrow the version range on the imports (using the versionpolicy) - without an export version bnd uses the bundle version as the default export version, but does not narrow the imports (because it picked the default export version itself, so it can't know if you expect to match lower bound imports). Anyway, if you set the version yourself then you're in control - otherwise the tools will do their best to provide reasonable defaults, but they may not match your intention (because it's impossible to infer that in all cases) > I join the maven project I used to make those tests (using "mvn clean > package" for each test): > http://old.nabble.com/file/p33206685/test.zip test.zip > -- > View this message in context: > http://old.nabble.com/maven-bundle-plugin-%3A-no-import-version-for-packages-being-both-imported-and-exported-after-a-clean-build-tp33200339p33206685.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
