Richard S. Hall wrote:
Alin Dreghiciu wrote:
A kind of "urgent" question:
Shall the exported packages of the wrapped jar contain the version of
the
jar? Something like:
<Export-Package>
*;version=${pom.version}
</Export-Package>
I assume by "version of the jar" you mean the released version of the
wrapped JAR. If the packages in foo.jar are versioned as a whole (like
most typical releases), then yes, the exported packages should be
exported with the associated version.
If the wrapped JAR contains various packages that are versioned
separately, then the various packages should have their corresponding
version.
Keep in mind that there will also be the Bundle-Version which is
independent of the package version. The package version should be the
one assigned by the original developer of the code. The Bundle-Version
will be assigned by the creator of the bundle wrapper pom...perhaps we
should adopt a common Bundle-Version for this first round.
I agree that there should be a separate version number for the
pom/Bundle-Version, but I don't think it should be independent of the
package version. RPM has the same issue: wrapping someone else's
deliverable and uniquely identifying it. The approach they have taken
is to add a release number to the wrapped deliverable's version number.
For example, when creating an RPM for gcc 4.1.1, the RPM version is the
gcc version with the RPM release number appended, e.g. 4.1.1-51. This
serves the purpose of making it obvious which version of gcc the RPM
contains, as well as uniquely identifying which RPM release of gcc 4.1.1
it is.
I think that we can reuse the RPM tactic like this:
:
<properties>
<shortName>FOO</shortName>
<pkgVersion>FOO's version</pkgVersion>
<pomVersion>1</pomVersion>
</properties>
:
<version>${pkgVersion}-${pomVersion}</version>
<description>This bundle simply wraps
${shortName}-${pkgVersion}.jar.</description>
:
<dependencies>
<dependency>
<groupId>FOO's groupId</groupId>
<artifactId>${shortName}</artifactId>
<version>${pkgVersion}</version>
</dependency>
</dependencies>
:
<Export-Package>*;version=${pkgVersion}</Export-Package>
:
Note: maven-bundle-plugin defaults Bundle-Version to be <version>.
As we refine the wrapping of a particular package, we increment
<pomVersion>.
Thoughts?
I just looked at commons-collections and (assuming that I am reading
the pom correctly) I think it may have been done incorrectly. It has
the overall bundle-version as 3.2 (i.e., it has
<version>3.2</version>), but doesn't appear to attach any version to
the packages. So, ultimately, this means that you would have an
exported package that looked like this:
Export-Package: foo; version=0.0.0; bundle-version=3.2.0
This is not what we want. We want to version our bundles according to
their degree own version history, so for example our first attempt
might be "0.8.0" or something, but the exported packages are whatever
the original developer says they are. So for commons-collections, we
really want to set <version>0.8.0</version> and tell BND to export
with version=3.2.0. Thus, we would end up with exports like:
Export-Package: foo; version=3.2.0; bundle-version=0.8.0
-> richard
