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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>

Reply via email to