[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Bundle directories

equinox-dev-bounces@xxxxxxxxxxx wrote on 09/21/2005 03:15:52 AM:

> Great! It would be fantastic if we could standardize this in the near
> future. I think I agree with most of your discussion except the
> following (argued further on):
> - Grouping versus requirements/capabilties

I'm certainly open here.  The main concern is that people not have to pick through individual bundles.  for example, if you search the bundles for "help" you might find 5 or 10 or more that have that in their name/description.  Which one do I get that is the root?  What about cases where there is no single root?  How do I get the "help" function?  

So it doesn't matter if it is implemented using features or capabilities or ... as long as the user is not burdened with seeing 1000s of bundles.

> - Install versus download

It is interesting to look at the main goal here.  Seems like the goal at this point is (should be?) to further the adoption of OSGi through easing adoption and broadening the base set of function.  Installing bundles is a runtime thing that very few people have to endure (end user products will ship with the bundles they need).  Developers on the other hand are always on the look out for new and interesting bundles, adding them to their target or build environment so they can code against them.  To me this is the group we need to cater to and attract.  They need to download bundles, not necessarily install them.

> Requirements from the OSGi point of view: (open for discussion)
> Federated - We do not want to physically host the bundles and cause
> some bottleneck in updating. From the OSGi web site it should be
> possible to detect any authorized repository. Then again, we want a
> single access point for convenience, though many repositories can
> exist.

Minor point but we should distinghish between diretories and repos.  From my limited understanding, Maven is a repo (with no directory), ORB is a directory (that points at various repos) and Update forces the two together.

> Distributions - Should be possible to get the source of a bundle, if
> provided.

Absolutely.  Doc and examples are other possibilities

> Dependencies - A general capability-requirement model is necessary. My
> preference is that this general model handles grouping, package and
> bundle dependencies. I am hesitant for a grouping model like Features
> because in my experience it is often not necessary and requires the
> author to make all possible combinations. I'd prefer to keep the model
> flat (just bundles) with relations (capability/requirements) that can
> be used to find out what is necessary and what is optional. For
> example fragments with translations should have optional requirement
> while an XML parser can be a mandatory requirement.

Yes, this sounds interesting.