Re: What about Felix Commons

[Richard S. Hall]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> > > On 3/8/07, Carlos Sanchez <[EMAIL PROTECTED]> 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
>> >
>>
>>
>