>From my POV I would also like to see somewhere the version of the wrapped
package.
+1 for wrapper having it's own version.
My proposal:
<major>.<minor>.<release>-<package-version>-SNAPSHOT
<major> - start with 0 and increment when something about felix is changed
that need refactoring in the wrappers
<minor> - start with 1 and increment as soon as the version of the wrapped
package changes
<release> - start with 0 and increment on every change on the pom
<package-version> - original package verison
SNAPSHOT - everybody knows :)
On 3/10/07, Tim Moloney <t.moloney@verizon.net> wrote:
>
> 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
> >
>
|