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 >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >