Return-Path: 
 <felix-dev-return-5069-apmail-incubator-felix-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org
Received: (qmail 97764 invoked from network); 11 Mar 2007 20:36:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Mar 2007 20:36:32 -0000
Received: (qmail 53123 invoked by uid 500); 11 Mar 2007 20:36:40 -0000
Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org
Received: (qmail 53084 invoked by uid 500); 11 Mar 2007 20:36:40 -0000
Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:felix-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:felix-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:felix-dev@incubator.apache.org>
List-Id: <felix-dev.incubator.apache.org>
Reply-To: felix-dev@incubator.apache.org
Delivered-To: mailing list felix-dev@incubator.apache.org
Received: (qmail 53073 invoked by uid 99); 11 Mar 2007 20:36:40 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 13:36:40 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [217.160.230.40] (HELO mout.perfora.net) (217.160.230.40)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 12:36:29 -0800
Received: from [70.141.2.14] (helo=[10.0.1.2])
	by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis),
	id 0MKp2t-1HQUly30GM-0007rT; Sun, 11 Mar 2007 16:36:08 -0400
Message-ID: <45F46835.9080107@ungoverned.org>
Date: Sun, 11 Mar 2007 16:36:05 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0b2 (X11/20070116)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: What about Felix Commons
References: <87eb8aee0703080407x2f57cfr76ede4088d04a70a@mail.gmail.com>
	 <1a5b6c410703081315q6c7ae068gfb7f612ee1750d6b@mail.gmail.com>
	 <87eb8aee0703082321o6c07d2e7p87c130d2b2b5a345@mail.gmail.com>
	 <87eb8aee0703090520ueaa20bah53427eb766e2f61c@mail.gmail.com>
	 <45F16BBF.7030803@ungoverned.org>
 <45F1FB7C.1090601@verizon.net>	 <87eb8aee0703101113r4956e669u29654a1e485f6b6e@mail.gmail.com>
	 <45F430C9.5040701@ungoverned.org>
	 <87eb8aee0703111310q70aa8ffbof604b417b320332@mail.gmail.com>
	 <45F4635D.8020009@ungoverned.org>
 <87eb8aee0703111329h6cf552capc755cffd89dfda85@mail.gmail.com>
In-Reply-To: <87eb8aee0703111329h6cf552capc755cffd89dfda85@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: perfora.net abuse@perfora.net
 login:b399c17105f59dfa36985f08f30e623d
X-Provags-ID2: V01U2FsdGVkX1+yXiYL/4+xJxE/H3LGsVXvvLfwF4jyebKkYWJ
 DtYWmd1EN0vbou8jawpbc0ejtmUniQpg7pzL/6coAXr95axSaW
 t99V+EF1Ew19IGvHrUNBpPssOqdX8fG
X-Virus-Checked: Checked by ClamAV on apache.org

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