felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alin Dreghiciu" <adreghi...@gmail.com>
Subject Re: What about Felix Commons
Date Fri, 09 Mar 2007 14:25:32 GMT
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 <heavy@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 <adreghiciu@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 <carlos@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 <enriquer9@gmail.com> wrote:
> >> > > On 3/8/07, Carlos Sanchez <carlos@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
> >> >
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message