Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-dev] Re: osgi manifest review

On Wed, Apr 1, 2009 at 13:59, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
> you cannot export foo.* but rather have to enumerate the packages.
> The main bulk of the info is related to the "uses" clauses.  There is some
> difference of opinion on these.  They are required for technical correctness
> to avoid some classloader issues.  They do however introduce the potential
> for very long resolultion times as the problem likely to be NP-complete.  We
> have a pretty good resolver but depending on the number of choices for a
> given requirement, there can be quite some work.
>
> In general if your manifests are reflective of reality then I would not
> worry about it.  They are there to describe things so if you really are
> related to others in the manner set out, great!

Great, I am staging the artifacts right now so we can have time to
review them before they are published...this makes it sound like we
are on the right track after all!

> The SNAPSHOT part of the version number is somewhat worrisome.  how is that
> going to evolve?  That is, if you build today and everything is
> 7.0.0.M0-SNAPSHOT, what will it be tomorrow? or tonight?  This applies to
> the bundle version and the package versions.  The content of a bundle should
> be uniquely identified by the symbolic name and version.  if the content
> changes and the version does not, people will be confused and provisioning
> systems just will not do any updates.

Generally speaking, people won't use those versions, for example what
we will be publishing with M0 will be version 7.0.0.M0, followed up
7.0.0.M1, etc etc...so -SNAPSHOT won't be a factor with these
artifacts.  I'll reply to this post later with example of an actual
manifest.

> On a different note, the import package version ranges should eventually
> have an upper bound.  As it is you are saying you will  work fine with
> version 10 of, for exampel, org.eclipse.jetty.http.  Perhaps but that is a
> tall order to say up front.  Given that we went for years without import
> versions at all, this is something you can address later.

what would this look like and I'll see about getting that addressed
sooner rather then later..


cheers!
jesse


Back to the top