Ok now I see it.
I sum it up to help me understand (and maybe help other readers if any):
1.
BND uses the bundle version as default value for the export of packages
without packageinfo.
But BND doesn't allow itself to narrow an import version based only on this
default version.
2.
BND uses all manifests found on the class-path to extract information about
imported packages without packageinfo and use it to narrow their version.
Because of the default value of the "manifestLocation" parameter, the
generated manifest is on the class-path.
3.
Therefore, when a package is exported without explicit version (i.e without
packageinfo nor export directive), the only source of information available
to compute its import version is a possible manifest on the class-path.
Hence the "mvn package" / "mvn clean package" inconsistency.
Workaround 1.
<Export-Package>{local-packages};version=${project.version}</Export-Package>
Explicit export version so no problem to compute the import.
Beware, will override any version from packageinfo files.
Workaround 2.
Execute the bundle:manifest goal just before the bundle:bundle goal.
Generating the manifest a first time allow bundle:bundle to scan it and get
the version from the export statement.
Beware, works only with "manifestLocation" pointing to a directory in the
class-path.
I'll think about opening a "clean / no clean" issue, but as you said, this
is a very specific case (and happens only when using not OSGi friendly
versioning).
Thanks again for digging into code and old issues.
/Thomas
--
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-tp33200339p33209064.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]
