Return-Path: 
 <felix-dev-return-5066-apmail-incubator-felix-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org
Received: (qmail 86695 invoked from network); 11 Mar 2007 20:11:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Mar 2007 20:11:23 -0000
Received: (qmail 34024 invoked by uid 500); 11 Mar 2007 20:11:30 -0000
Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org
Received: (qmail 33995 invoked by uid 500); 11 Mar 2007 20:11:30 -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 33977 invoked by uid 99); 11 Mar 2007 20:11:30 -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:11:30 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of adreghiciu@gmail.com
 designates 66.249.92.171 as permitted sender)
Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 12:11:19 -0800
Received: by ug-out-1314.google.com with SMTP id y2so2343294uge
        for <felix-dev@incubator.apache.org>;
 Sun, 11 Mar 2007 13:10:57 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=YJVzj1rqs2pXJfHTwKiNnH+4G1LbJDm4xOxYp7Bla+fp7fUxqFLlSnLJDsm5Vn40AravS18c2YVNN+QGl5GTjrXwWVZLMptx0YE7LVYfJXdu0AgLSyS3zs0QWhobvaRXSDDyzf9IO92qe8jk4Oe2+vyA2JHbXE1KpAEJmmCNYsU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Q5dPB+Yn+HrKhA7cjDAgRPr/6SjK8jTr33UtmSMyKp0r/dSnrPviCRyeyVbkjS6spAWUgGFEh2nz3pb37EhOSEh2jJk/y2M5cChOZ+m8jwjLd7lr+CKHaJOQy8NyRrPkE/1eJYQ5Q6QMXDDL8YTumaqLgN+kRMj+VHPN0LOSWTQ=
Received: by 10.114.177.1 with SMTP id z1mr987825wae.1173643856231;
        Sun, 11 Mar 2007 13:10:56 -0700 (PDT)
Received: by 10.115.74.17 with HTTP; Sun, 11 Mar 2007 13:10:56 -0700 (PDT)
Message-ID: <87eb8aee0703111310q70aa8ffbof604b417b320332@mail.gmail.com>
Date: Sun, 11 Mar 2007 22:10:56 +0200
From: "Alin Dreghiciu" <adreghiciu@gmail.com>
To: felix-dev@incubator.apache.org
Subject: Re: What about Felix Commons
In-Reply-To: <45F430C9.5040701@ungoverned.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_20715_30329710.1173643856178"
References: <87eb8aee0703080407x2f57cfr76ede4088d04a70a@mail.gmail.com>
	 <1a5b6c410703081141s58a5f45br848f912e3a6dbfea@mail.gmail.com>
	 <568753d90703081249g5644d3aeue32866d5d1880605@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>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_20715_30329710.1173643856178
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

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

------=_Part_20715_30329710.1173643856178--