Re: [equinox-dev] Bundle directories

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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.

Jeff