You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alin Dreghiciu <ad...@gmail.com> on 2007/03/08 13:07:42 UTC
What about Felix Commons
Hi,
I started to post jira issues for wrapping bundles as part of felix
commons, after a discussion with Richard S. Hall we had on spring-osgi
forum. Sping-osgi development has a set of required dependencies on
third party jars and I'm trying now to push for moving them to felix
commons since the scope of the project is not to provide this jars.
And I'm also looking for having just one common repository for this
kind of artifacts so adoption of osgi to be easier.
As this to become a reality I would like to the wrapped bundles
available for download so,. I would not have to checkout also felix
commons and build it my self.
So, my question: What's the plan Enrique?
When can I expect those bundles available on the m2 incubating
repository? Are there missing bits that stops this process?
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alin Dreghiciu wrote:
> I'm talking about the package version. I'm going now by a revision of all
> wrappings I made and I want also to add the version to the exported
> package.
I figured, but we will still need to address the potential incorrect
approach below for existing POM files:
>> 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
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
I'm talking about the package version. I'm going now by a revision of all
wrappings I made and I want also to add the version to the exported package.
On 3/9/07, Richard S. Hall <he...@ungoverned.org> 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 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
>
> >
> > Alin Dreghiciu
> >
> > On 3/9/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> >>
> >> Thanx Enrique,
> >>
> >> I will update some of the pom's that I posted today so you will have
> >> them
> >> for weekend.
> >> I agree with Carlos that we should get the ball rolling and use them.
> >> Later one we can refactor.
> >>
> >> Alin Dreghiciu
> >>
> >> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> >> >
> >> > this is the first step, having a public place for consumption of osgi
> >> > bundles, with osgi manifests and OBR metadata.
> >> > I'm still puting all pieces together for osgi-maven relation, I'll
> >> > keep informe after i digest all the stuff i'm finding out ;)
> >> >
> >> > On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> >> > > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> >> > > > I'm also interested on this, i was talking with several people at
> >> > > > EclipseCON and also here on the list, and seems that having an
> >> > > > equivalent to the maven repository with osgi bundles and OBR
> >> > metadata
> >> > > > would be a good way to go.
> >> > >
> >> > > Would anything change at the same time about how m2 processes
> >> > > transitive dependencies? How could this repo support better the
> >> > > "Import/Export" model (as opposed to the "Require Bundle" model)?
> >> > >
> >> > > It would be nice to better align m2 with the OSGi "Import/Export"
> >> > > model. In any case, seeing OSGi with first-class support in m2
> >> would
> >> > > be great.
> >> > >
> >> > > Enrique
> >> > >
> >> >
> >> >
> >> > --
> >> > I could give you my word as a Spaniard.
> >> > No good. I've known too many Spaniards.
> >> > -- The Princess Bride
> >> >
> >>
> >>
> >
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alin Dreghiciu wrote:
> Regarding naming of the artifacts, shall we use the parent version, so
> for
> example now ${parent.version} = 0.9.0-SNAPSHOT ?
Not necessarily. That was the point I was trying to make with my other
message. Our wrapper bundles have their own version number which is the
version of the wrapped bundle JAR file (which is conceptually different
that the parent pom version and is different than the version of the
original JAR). In the future if we update our wrapper pom.xml file
(e.g., to be more accurate or if there was a mistake), then we should
increment the version of the pom.xml to indicate that we have released a
new version of our wrapped library, this would be independent of the
parent version.
I think you should just pick a version number, it doesn't really matter,
except that it should include SNAPSHOT since it will be published to the
snapshot repo for now. If we are following the scheme of odd being
development releases, then you could pick any of 0.[13579].0-SNAPSHOT,
for example. Then when we finally release these into a non-snapshot
repo, we can increment the version to the nearest "even" number.
Just my thinking...
-> richard
>
> On 3/9/07, Richard S. Hall <he...@ungoverned.org> 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 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
>>
>> >
>> > Alin Dreghiciu
>> >
>> > On 3/9/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> >>
>> >> Thanx Enrique,
>> >>
>> >> I will update some of the pom's that I posted today so you will have
>> >> them
>> >> for weekend.
>> >> I agree with Carlos that we should get the ball rolling and use them.
>> >> Later one we can refactor.
>> >>
>> >> Alin Dreghiciu
>> >>
>> >> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
>> >> >
>> >> > this is the first step, having a public place for consumption of
>> osgi
>> >> > bundles, with osgi manifests and OBR metadata.
>> >> > I'm still puting all pieces together for osgi-maven relation, I'll
>> >> > keep informe after i digest all the stuff i'm finding out ;)
>> >> >
>> >> > On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
>> >> > > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
>> >> > > > I'm also interested on this, i was talking with several
>> people at
>> >> > > > EclipseCON and also here on the list, and seems that having an
>> >> > > > equivalent to the maven repository with osgi bundles and OBR
>> >> > metadata
>> >> > > > would be a good way to go.
>> >> > >
>> >> > > Would anything change at the same time about how m2 processes
>> >> > > transitive dependencies? How could this repo support better the
>> >> > > "Import/Export" model (as opposed to the "Require Bundle" model)?
>> >> > >
>> >> > > It would be nice to better align m2 with the OSGi "Import/Export"
>> >> > > model. In any case, seeing OSGi with first-class support in m2
>> >> would
>> >> > > be great.
>> >> > >
>> >> > > Enrique
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > I could give you my word as a Spaniard.
>> >> > No good. I've known too many Spaniards.
>> >> > -- The Princess Bride
>> >> >
>> >>
>> >>
>> >
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Regarding naming of the artifacts, shall we use the parent version, so for
example now ${parent.version} = 0.9.0-SNAPSHOT ?
On 3/9/07, Richard S. Hall <he...@ungoverned.org> 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 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
>
> >
> > Alin Dreghiciu
> >
> > On 3/9/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> >>
> >> Thanx Enrique,
> >>
> >> I will update some of the pom's that I posted today so you will have
> >> them
> >> for weekend.
> >> I agree with Carlos that we should get the ball rolling and use them.
> >> Later one we can refactor.
> >>
> >> Alin Dreghiciu
> >>
> >> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> >> >
> >> > this is the first step, having a public place for consumption of osgi
> >> > bundles, with osgi manifests and OBR metadata.
> >> > I'm still puting all pieces together for osgi-maven relation, I'll
> >> > keep informe after i digest all the stuff i'm finding out ;)
> >> >
> >> > On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> >> > > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> >> > > > I'm also interested on this, i was talking with several people at
> >> > > > EclipseCON and also here on the list, and seems that having an
> >> > > > equivalent to the maven repository with osgi bundles and OBR
> >> > metadata
> >> > > > would be a good way to go.
> >> > >
> >> > > Would anything change at the same time about how m2 processes
> >> > > transitive dependencies? How could this repo support better the
> >> > > "Import/Export" model (as opposed to the "Require Bundle" model)?
> >> > >
> >> > > It would be nice to better align m2 with the OSGi "Import/Export"
> >> > > model. In any case, seeing OSGi with first-class support in m2
> >> would
> >> > > be great.
> >> > >
> >> > > Enrique
> >> > >
> >> >
> >> >
> >> > --
> >> > I could give you my word as a Spaniard.
> >> > No good. I've known too many Spaniards.
> >> > -- The Princess Bride
> >> >
> >>
> >>
> >
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Wonderful, thanx for your feedback.
Related to this,
http://opensource.atlassian.com/projects/spring/browse/OSGI-84
http://opensource.atlassian.com/projects/spring/browse/OSGI-85
I hope that they will decide to go this way and then more will come.
On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 3/13/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > Enrique,
> >
> > Could you tell me what's the status by now?
>
> I got the feedback I wanted before rolling this out, so I'll do it today.
>
> > Shall I help and refactor the pom's according to the latest discussions?
>
> No, I have everything local and ready to commit. I'll touch up the
> shortName --> pkgArtifactId. Also, I want to test with the bnd
> mentioned by Tim, since that clears up a couple bundles.
>
> Enrique
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Just repeating my question bellow:
Any idea when will this bundles be available in any repository?
On 3/14/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>
> Any idea when will this bundles be available in any repository? Maybe
> http://people.apache.org/maven-snapshot-repository/org/apache/felix
>
> Alin Dreghiciu
>
> On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
> >
> > On 3/13/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > > Enrique,
> > >
> > > Could you tell me what's the status by now?
> >
> > I got the feedback I wanted before rolling this out, so I'll do it
> > today.
> >
> > > Shall I help and refactor the pom's according to the latest
> > discussions?
> >
> > No, I have everything local and ready to commit. I'll touch up the
> > shortName --> pkgArtifactId. Also, I want to test with the bnd
> > mentioned by Tim, since that clears up a couple bundles.
> >
> > Enrique
> >
>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Any idea when will this bundles be available in any repository? Maybe
http://people.apache.org/maven-snapshot-repository/org/apache/felix
Alin Dreghiciu
On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 3/13/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > Enrique,
> >
> > Could you tell me what's the status by now?
>
> I got the feedback I wanted before rolling this out, so I'll do it today.
>
> > Shall I help and refactor the pom's according to the latest discussions?
>
> No, I have everything local and ready to commit. I'll touch up the
> shortName --> pkgArtifactId. Also, I want to test with the bnd
> mentioned by Tim, since that clears up a couple bundles.
>
> Enrique
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Enrique Rodriguez wrote:
> On 3/13/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> Enrique,
>>
>> Could you tell me what's the status by now?
>
> I got the feedback I wanted before rolling this out, so I'll do it today.
>
>> Shall I help and refactor the pom's according to the latest discussions?
>
> No, I have everything local and ready to commit. I'll touch up the
> shortName --> pkgArtifactId. Also, I want to test with the bnd
> mentioned by Tim, since that clears up a couple bundles.
This is looking good. I doubt we will get it right the first time, but I
think this is closer already. Good work.
-> richard
Re: What about Felix Commons
Posted by Enrique Rodriguez <en...@gmail.com>.
On 3/13/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> Enrique,
>
> Could you tell me what's the status by now?
I got the feedback I wanted before rolling this out, so I'll do it today.
> Shall I help and refactor the pom's according to the latest discussions?
No, I have everything local and ready to commit. I'll touch up the
shortName --> pkgArtifactId. Also, I want to test with the bnd
mentioned by Tim, since that clears up a couple bundles.
Enrique
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Enrique,
Could you tell me what's the status by now?
Shall I help and refactor the pom's according to the latest discussions?
Alin Dreghiciu
On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > Take a look at an example:
> https://issues.apache.org/jira/browse/FELIX-240
> > I had to add a new property: osgiVersion because pakage version does not
> > always conforms to osgi format. As in the example above the package
> > was 2.2but becasue of the pom version and snapshot the version will be
> > 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the
> package
> > version and adds .0
>
> So, I think I'm caught up on these threads OK. I merged the above
> latest round of thinking on the versioning scheme with the earlier
> thread regarding the shortName. The gist of it is that with:
>
> <properties>
> <shortName>commons-attributes-api</shortName>
>
> <pkgVersion>2.2</pkgVersion>
>
> <pomVersion>0001</pomVersion>
>
> <osgiVersion>${pkgVersion}.0</osgiVersion>
>
> </properties>
> ...
> <groupId>org.apache.felix.commons</groupId>
>
> <artifactId>${pom.groupId}.${shortName}</artifactId>
>
> <version>${osgiVersion}-${pomVersion}-SNAPSHOT</version>
>
> ... you get an artifact named:
>
> org.apache.felix.commons.commons-attributes-api-2.2.0-0001-SNAPSHOT.jar
>
> On the bright side, with the "SNAPSHOT" and the fact that
> "commons-attributes-api" is about as long as they come to begin with,
> I think this is a worst case scenario in terms of length.
>
> The manifest looked good, including the package versioning.
>
> Is that what we want? Did I get that right?
>
> Enrique
>
Re: What about Felix Commons
Posted by Tim Moloney <t....@verizon.net>.
As long as the functionality remains the same (the original package
name), I don't care much what it is called. Enrique didn't include the
whole script but that property/variable is very useful.
pkgArtifactId is more descriptive. Let's use it.
Tim
Alin Dreghiciu wrote:
> I would think again about the shortName. First is not very suggestive
> (name
> of what?) and second it will make people invent new names for the same
> stuff. I would go for something as
> <pkgArtifactId>commons-attributes-api</pkgArtifactId> and the value to
> always match the
> original package.
>
> Alin
>
> On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
>>
>> On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> > Take a look at an example:
>> https://issues.apache.org/jira/browse/FELIX-240
>> > I had to add a new property: osgiVersion because pakage version
>> does not
>> > always conforms to osgi format. As in the example above the package
>> > was 2.2but becasue of the pom version and snapshot the version will be
>> > 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the
>> package
>> > version and adds .0
>>
>> So, I think I'm caught up on these threads OK. I merged the above
>> latest round of thinking on the versioning scheme with the earlier
>> thread regarding the shortName. The gist of it is that with:
>>
>> <properties>
>> <shortName>commons-attributes-api</shortName>
>>
>> <pkgVersion>2.2</pkgVersion>
>>
>> <pomVersion>0001</pomVersion>
>>
>> <osgiVersion>${pkgVersion}.0</osgiVersion>
>>
>> </properties>
>> ...
>> <groupId>org.apache.felix.commons</groupId>
>>
>> <artifactId>${pom.groupId}.${shortName}</artifactId>
>>
>> <version>${osgiVersion}-${pomVersion}-SNAPSHOT</version>
>>
>> ... you get an artifact named:
>>
>> org.apache.felix.commons.commons-attributes-api-2.2.0-0001-SNAPSHOT.jar
>>
>> On the bright side, with the "SNAPSHOT" and the fact that
>> "commons-attributes-api" is about as long as they come to begin with,
>> I think this is a worst case scenario in terms of length.
>>
>> The manifest looked good, including the package versioning.
>>
>> Is that what we want? Did I get that right?
>>
>> Enrique
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
I would think again about the shortName. First is not very suggestive (name
of what?) and second it will make people invent new names for the same
stuff. I would go for something as
<pkgArtifactId>commons-attributes-api</pkgArtifactId> and the value to
always match the
original package.
Alin
On 3/13/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > Take a look at an example:
> https://issues.apache.org/jira/browse/FELIX-240
> > I had to add a new property: osgiVersion because pakage version does not
> > always conforms to osgi format. As in the example above the package
> > was 2.2but becasue of the pom version and snapshot the version will be
> > 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the
> package
> > version and adds .0
>
> So, I think I'm caught up on these threads OK. I merged the above
> latest round of thinking on the versioning scheme with the earlier
> thread regarding the shortName. The gist of it is that with:
>
> <properties>
> <shortName>commons-attributes-api</shortName>
>
> <pkgVersion>2.2</pkgVersion>
>
> <pomVersion>0001</pomVersion>
>
> <osgiVersion>${pkgVersion}.0</osgiVersion>
>
> </properties>
> ...
> <groupId>org.apache.felix.commons</groupId>
>
> <artifactId>${pom.groupId}.${shortName}</artifactId>
>
> <version>${osgiVersion}-${pomVersion}-SNAPSHOT</version>
>
> ... you get an artifact named:
>
> org.apache.felix.commons.commons-attributes-api-2.2.0-0001-SNAPSHOT.jar
>
> On the bright side, with the "SNAPSHOT" and the fact that
> "commons-attributes-api" is about as long as they come to begin with,
> I think this is a worst case scenario in terms of length.
>
> The manifest looked good, including the package versioning.
>
> Is that what we want? Did I get that right?
>
> Enrique
>
Re: What about Felix Commons
Posted by Tim Moloney <t....@verizon.net>.
Enrique Rodriguez wrote:
> On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> Take a look at an example:
>> https://issues.apache.org/jira/browse/FELIX-240
>> I had to add a new property: osgiVersion because pakage version does not
>> always conforms to osgi format. As in the example above the package
>> was 2.2but becasue of the pom version and snapshot the version will be
>> 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the
>> package
>> version and adds .0
>
> So, I think I'm caught up on these threads OK. I merged the above
> latest round of thinking on the versioning scheme with the earlier
> thread regarding the shortName. The gist of it is that with:
>
> <properties>
> <shortName>commons-attributes-api</shortName>
>
> <pkgVersion>2.2</pkgVersion>
>
> <pomVersion>0001</pomVersion>
>
> <osgiVersion>${pkgVersion}.0</osgiVersion>
>
> </properties>
> ...
> <groupId>org.apache.felix.commons</groupId>
>
> <artifactId>${pom.groupId}.${shortName}</artifactId>
>
> <version>${osgiVersion}-${pomVersion}-SNAPSHOT</version>
>
> ... you get an artifact named:
>
> org.apache.felix.commons.commons-attributes-api-2.2.0-0001-SNAPSHOT.jar
>
> On the bright side, with the "SNAPSHOT" and the fact that
> "commons-attributes-api" is about as long as they come to begin with,
> I think this is a worst case scenario in terms of length.
>
> The manifest looked good, including the package versioning.
>
> Is that what we want? Did I get that right?
>
> Enrique
>
I think you have captured everything that was discussed in this thread.
Thanks. :)
Tim
Re: What about Felix Commons
Posted by Enrique Rodriguez <en...@gmail.com>.
On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> Take a look at an example: https://issues.apache.org/jira/browse/FELIX-240
> I had to add a new property: osgiVersion because pakage version does not
> always conforms to osgi format. As in the example above the package
> was 2.2but becasue of the pom version and snapshot the version will be
> 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the package
> version and adds .0
So, I think I'm caught up on these threads OK. I merged the above
latest round of thinking on the versioning scheme with the earlier
thread regarding the shortName. The gist of it is that with:
<properties>
<shortName>commons-attributes-api</shortName>
<pkgVersion>2.2</pkgVersion>
<pomVersion>0001</pomVersion>
<osgiVersion>${pkgVersion}.0</osgiVersion>
</properties>
...
<groupId>org.apache.felix.commons</groupId>
<artifactId>${pom.groupId}.${shortName}</artifactId>
<version>${osgiVersion}-${pomVersion}-SNAPSHOT</version>
... you get an artifact named:
org.apache.felix.commons.commons-attributes-api-2.2.0-0001-SNAPSHOT.jar
On the bright side, with the "SNAPSHOT" and the fact that
"commons-attributes-api" is about as long as they come to begin with,
I think this is a worst case scenario in terms of length.
The manifest looked good, including the package versioning.
Is that what we want? Did I get that right?
Enrique
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
A proposal:
pkgVersion: 1.0RC1, 1.0RC2, 0.8-alpha
osgiVersion: 1.0.0.RC1, 1.0.0.RC2, 0.8.0.alpha
looks fine to me.
On 3/13/07, Stefano Lenzi <ki...@interfree.it> wrote:
>
> Alin Dreghiciu wrote:
> > Take a look at an example:
> https://issues.apache.org/jira/browse/FELIX-240
> > I had to add a new property: osgiVersion because pakage version does not
> > always conforms to osgi format. As in the example above the package
> > was 2.2but becasue of the pom version and snapshot the version will be
> > 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the
> package
> > version and adds .0
> >
> What about if we have to wrap jars that use "named version" like:
> 1.0RC1, 1.0RC2, 0.8-alpha, etc ?
>
> Is that a real issue? Or we are speaking about only of Maven artifact so
> none of the jars will have a "named version".
>
> Stefano Lenzi
>
Re: What about Felix Commons
Posted by Stefano Lenzi <ki...@interfree.it>.
Alin Dreghiciu wrote:
> Take a look at an example: https://issues.apache.org/jira/browse/FELIX-240
> I had to add a new property: osgiVersion because pakage version does not
> always conforms to osgi format. As in the example above the package
> was 2.2but becasue of the pom version and snapshot the version will be
> 2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the package
> version and adds .0
>
What about if we have to wrap jars that use "named version" like:
1.0RC1, 1.0RC2, 0.8-alpha, etc ?
Is that a real issue? Or we are speaking about only of Maven artifact so
none of the jars will have a "named version".
Stefano Lenzi
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Take a look at an example: https://issues.apache.org/jira/browse/FELIX-240
I had to add a new property: osgiVersion because pakage version does not
always conforms to osgi format. As in the example above the package
was 2.2but becasue of the pom version and snapshot the version will be
2.2.0001-SNAPSHOT which is invalid. so the osgi version reuses the package
version and adds .0
On 3/12/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>
> 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 <he...@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 <he...@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
> > >> >> >> >> >
> > >> >> >> >>
> > >> >> >> >
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >
> > >>
> > >
> >
>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <he...@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 <he...@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 <he...@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 <he...@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....@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
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <he...@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 <he...@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 <he...@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....@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
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 :)
On 3/11/07, Richard S. Hall <he...@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 <he...@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 <he...@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....@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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.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 <he...@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 <he...@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....@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
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
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.
On 3/11/07, Richard S. Hall <he...@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 <he...@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....@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
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <he...@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....@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
>> >> >
>> >>
>> >
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <he...@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....@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
> >> >
> >>
> >
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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....@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
>> >
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
>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 :)
On 3/10/07, Tim Moloney <t....@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
> >
>
Re: What about Felix Commons
Posted by Tim Moloney <t....@verizon.net>.
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
>
Re: What about Felix Commons
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 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
>
> Alin Dreghiciu
>
> On 3/9/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>>
>> Thanx Enrique,
>>
>> I will update some of the pom's that I posted today so you will have
>> them
>> for weekend.
>> I agree with Carlos that we should get the ball rolling and use them.
>> Later one we can refactor.
>>
>> Alin Dreghiciu
>>
>> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
>> >
>> > this is the first step, having a public place for consumption of osgi
>> > bundles, with osgi manifests and OBR metadata.
>> > I'm still puting all pieces together for osgi-maven relation, I'll
>> > keep informe after i digest all the stuff i'm finding out ;)
>> >
>> > On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
>> > > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
>> > > > I'm also interested on this, i was talking with several people at
>> > > > EclipseCON and also here on the list, and seems that having an
>> > > > equivalent to the maven repository with osgi bundles and OBR
>> > metadata
>> > > > would be a good way to go.
>> > >
>> > > Would anything change at the same time about how m2 processes
>> > > transitive dependencies? How could this repo support better the
>> > > "Import/Export" model (as opposed to the "Require Bundle" model)?
>> > >
>> > > It would be nice to better align m2 with the OSGi "Import/Export"
>> > > model. In any case, seeing OSGi with first-class support in m2
>> would
>> > > be great.
>> > >
>> > > Enrique
>> > >
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> > -- The Princess Bride
>> >
>>
>>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
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>
Alin Dreghiciu
On 3/9/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>
> Thanx Enrique,
>
> I will update some of the pom's that I posted today so you will have them
> for weekend.
> I agree with Carlos that we should get the ball rolling and use them.
> Later one we can refactor.
>
> Alin Dreghiciu
>
> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> >
> > this is the first step, having a public place for consumption of osgi
> > bundles, with osgi manifests and OBR metadata.
> > I'm still puting all pieces together for osgi-maven relation, I'll
> > keep informe after i digest all the stuff i'm finding out ;)
> >
> > On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > I'm also interested on this, i was talking with several people at
> > > > EclipseCON and also here on the list, and seems that having an
> > > > equivalent to the maven repository with osgi bundles and OBR
> > metadata
> > > > would be a good way to go.
> > >
> > > Would anything change at the same time about how m2 processes
> > > transitive dependencies? How could this repo support better the
> > > "Import/Export" model (as opposed to the "Require Bundle" model)?
> > >
> > > It would be nice to better align m2 with the OSGi "Import/Export"
> > > model. In any case, seeing OSGi with first-class support in m2 would
> > > be great.
> > >
> > > Enrique
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
>
>
Re: What about Felix Commons
Posted by Alin Dreghiciu <ad...@gmail.com>.
Thanx Enrique,
I will update some of the pom's that I posted today so you will have them
for weekend.
I agree with Carlos that we should get the ball rolling and use them.
Later one we can refactor.
Alin Dreghiciu
On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
>
> this is the first step, having a public place for consumption of osgi
> bundles, with osgi manifests and OBR metadata.
> I'm still puting all pieces together for osgi-maven relation, I'll
> keep informe after i digest all the stuff i'm finding out ;)
>
> On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > I'm also interested on this, i was talking with several people at
> > > EclipseCON and also here on the list, and seems that having an
> > > equivalent to the maven repository with osgi bundles and OBR metadata
> > > would be a good way to go.
> >
> > Would anything change at the same time about how m2 processes
> > transitive dependencies? How could this repo support better the
> > "Import/Export" model (as opposed to the "Require Bundle" model)?
> >
> > It would be nice to better align m2 with the OSGi "Import/Export"
> > model. In any case, seeing OSGi with first-class support in m2 would
> > be great.
> >
> > Enrique
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
Re: What about Felix Commons
Posted by Carlos Sanchez <ca...@apache.org>.
this is the first step, having a public place for consumption of osgi
bundles, with osgi manifests and OBR metadata.
I'm still puting all pieces together for osgi-maven relation, I'll
keep informe after i digest all the stuff i'm finding out ;)
On 3/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> > I'm also interested on this, i was talking with several people at
> > EclipseCON and also here on the list, and seems that having an
> > equivalent to the maven repository with osgi bundles and OBR metadata
> > would be a good way to go.
>
> Would anything change at the same time about how m2 processes
> transitive dependencies? How could this repo support better the
> "Import/Export" model (as opposed to the "Require Bundle" model)?
>
> It would be nice to better align m2 with the OSGi "Import/Export"
> model. In any case, seeing OSGi with first-class support in m2 would
> be great.
>
> Enrique
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: What about Felix Commons
Posted by Enrique Rodriguez <en...@gmail.com>.
On 3/8/07, Carlos Sanchez <ca...@apache.org> wrote:
> I'm also interested on this, i was talking with several people at
> EclipseCON and also here on the list, and seems that having an
> equivalent to the maven repository with osgi bundles and OBR metadata
> would be a good way to go.
Would anything change at the same time about how m2 processes
transitive dependencies? How could this repo support better the
"Import/Export" model (as opposed to the "Require Bundle" model)?
It would be nice to better align m2 with the OSGi "Import/Export"
model. In any case, seeing OSGi with first-class support in m2 would
be great.
Enrique
Re: What about Felix Commons
Posted by Carlos Sanchez <ca...@apache.org>.
I'm also interested on this, i was talking with several people at
EclipseCON and also here on the list, and seems that having an
equivalent to the maven repository with osgi bundles and OBR metadata
would be a good way to go.
On 3/8/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> Hi,
>
> I started to post jira issues for wrapping bundles as part of felix
> commons, after a discussion with Richard S. Hall we had on spring-osgi
> forum. Sping-osgi development has a set of required dependencies on
> third party jars and I'm trying now to push for moving them to felix
> commons since the scope of the project is not to provide this jars.
> And I'm also looking for having just one common repository for this
> kind of artifacts so adoption of osgi to be easier.
>
> As this to become a reality I would like to the wrapped bundles
> available for download so,. I would not have to checkout also felix
> commons and build it my self.
>
> So, my question: What's the plan Enrique?
> When can I expect those bundles available on the m2 incubating
> repository? Are there missing bits that stops this process?
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: What about Felix Commons
Posted by Enrique Rodriguez <en...@gmail.com>.
On 3/8/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> ...
> So, my question: What's the plan Enrique?
> When can I expect those bundles available on the m2 incubating
> repository? Are there missing bits that stops this process?
I have a big commit going in on another project these days, but my
plan is to commit all the wrapper POM's this weekend. I can also
deploy this weekend if everyone's happy with the latest round of
debate on the naming convention (I'm happy). I don't think there are
any missing pieces and in any case I can figure them out when I get to
processing the JIRA issues. Thanks for submitting individual JIRA
issues.
Enrique