Take a look at an example: https://issues.apache.org/jira/browse/FELIX-240
I had to add a new property: osgiVersion because pakage version does not
always conforms to osgi format. As in the example above the package
was 2.2but becasue of the pom version and snapshot the version will be
2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the package
version and adds .0
On 3/12/07, Alin Dreghiciu <adreghiciu@gmail.com> wrote:
>
> 4 digits in total? 9999 builds seems reasonable for now. I hope that those
> packages will get bundles by the time we run out of numbers :)
>
> On 3/12/07, Richard S. Hall <heavy@ungoverned.org> wrote:
> >
> > Alin Dreghiciu wrote:
> > > Right. we could use an 0 fill before as 00100 and 00050. Or, let's use
> > my
> > > proposal with only two positions:
> > > macro - incremented when wrapped package changes
> > > minor - incremented when something changes in the wrapper and is
> > > about teh
> > > same wrapped package number. And s reset to 0 when macro changes.
> > >
> > > Alin Dreghiciu
> > >
> > > P.S. is atrted to like to Tim's idea, seams more natural :)
> >
> > Me too. We can do like you say, with zero padding to get it to work, I
> > suppose.
> >
> > -> richard
> >
> > >
> > > On 3/11/07, Richard S. Hall <heavy@ungoverned.org> wrote:
> > >>
> > >> Alin Dreghiciu wrote:
> > >> > 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.
> > >>
> > >> But my concern is that String.compareTo() is not going to be correct,
> >
> > >> e.g
> > >> .,:
> > >>
> > >> "100" < "50"
> > >>
> > >> -> richard
> > >>
> > >> >
> > >> > On 3/11/07, Richard S. Hall < heavy@ungoverned.org> 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 <heavy@ungoverned.org >
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 < 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
> > >> >> >> >> >
> > >> >> >> >>
> > >> >> >> >
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >
> > >>
> > >
> >
>
>
|