felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alin Dreghiciu" <adreghi...@gmail.com>
Subject Re: What about Felix Commons
Date Mon, 12 Mar 2007 07:02:10 GMT
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
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message