You are right. I was too lazy to check the specs. Chapter 3.5.3 is pretty
clear about this.
So, we ave a deal?
Wrapper version will be composed from the original version and the build
number as: <wrapped_package_version>-<wrapper_version>
where wrapper_version starts by 0 and is incremented every time teh wrapper
pom is changed.
On 3/11/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Alin Dreghiciu wrote:
> Maven I'm not sure, I have to check. Osgi? for sure not, but
> maven-undle-plugin will transform it to
> <major>.<minor>.<release>.<package-version>.SNAPSHOT (I guess, if I
> recall
> correctly the code which seems a valid version for a bundle (yet not
very
> sure about the dot before SNAPSHOT).
> Tim's proposal seems find to me also but will end up as an OSGi
> version as
> in his example 4.1.1.51 where 51 will not be relevant for version
> resolving
> in OSGi . So , will be hard to express the dependency on a certain
> wrapper
> version.
51 is relevant, it is just compared by String.compareTo()...
-> richard
>
> Alin Dreghiciu
>
> On 3/11/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>>
>> Alin Dreghiciu wrote:
>> > 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 :)
>>
>> I think I prefer Tim's proposal below and it seems to give you want you
>> want anyway, since the "release number" effectively becomes the version
>> of the wrapper. However, I am not sure how Maven will deal with
versions
>> in this format? Will it be able to tell the latest version? Or even
OSGi
>> for that matter, since the qualifier is compared using String.compareTo
>> ()...
>>
>> -> richard
>>
>> >
>> > On 3/10/07, Tim Moloney <[EMAIL PROTECTED]> 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
>> >> >
>> >>
>> >
>>
>
