Re: Re: Re: [platform-update-dev] Investigating some alternative update

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

On 15/09/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> Alex, thanks for taking the time to put down all that detail.  I'm not at
> all opposed to what you describe.  I do have some observations
>
> - bundle dependencies as expressed in the manifest.mf are not enough for
> provisioning.  The help system is illustrative here...

Yes, I agree that (as it stands) there are these sorts of separations;
I think that in the case of services (generally) you will have this
problem; but in general, also some where Import-Package is being used.
Let's stick with the services example ...

However, let's assume that we have help.ui, which (from a manifest
PoV) declares a dependency on help (but not help.server, without which
it cannot operate). In the current system, you would have a feature
that contained help.ui, help and help.server.

One suggestion is that we have a meta-bundle, help.all, that declares
a dependency on help.ui, help, and help.server. In this case, the
meta-bundle plays the part of the feature in any case; they're
basically exposing the same dependencies.

If there's any OS-specific issues (e.g. needing filesystem.win32 or
filesystem.macosx) these too can be incorporated, through a selector
on the Requires-Bundle package. In fact, it would use the same
selector syntax that is currently present for determining availability
of e.g. Bundle-NativeCode.

The other observation is that the atom entries do not have to be based
solely on the Manifest; in fact, whilst it would probably make sense
(by default) for it to be calculated from the Manifest, in fact it
would be something that you could add/edit manually after the fact.
I'd imagine that an XML format, including the dependencies (e.g.
optional/required/OS or HW selector) would be created. (Hey, we could
just re-use the feature.xml syntax, though I'd recommend that it be
appropriately namespaced and relax the restrictions such that other
namespaces can be intermingled or extended at a later stage.)

So whilst in the simple case, you could derive the Atom entry
appropriately from the Manifest (e.g. for Xalan depends on Xerces) you
could add extra information to it for the help server case.

> - similarly, some logical groupings consist of disparate functional pieces.
> I might want CDT and JDT but have no plugin that depends on both directly.

I don't see that as being a problem. In order to have CDT and JDT,
you'd just end up with two Atom feeds. An update site may contain many
such atom feeds at a top-level index; in my example, the Atom feeds
for CDT and JDT would be distinct. And, as both are separate, any
updates to either Atom feed would update CDT or JDT directly.

(an uber-update site could choose to merge both the CDT and JDT feeds
into a single aggregated feed, or -- more likely -- there would be a
feed-of-feeds that allowed them to be broken down into individual
units)

> - groupings that are logical must, in general, be crafted by developers.
>  They cannot be generated or discovered automatically.

I think we should acknowledge that there are things that cannot be
discovered automatically. However, there are some that can. I propose
that a separate syntax is used to denote these in both cases; for the
logical one, it must be provided manually (much like the feature.xml
is used today). However, it doesn't preclude in simple cases it being
generated and used automatically.

> - Features include a notion of "selection".  Take a look at the SWT fragment
> entries in the RCP feature.  You will see a mess of things like os="win32"
> ws="win32" etc.  These are selectors that basically say "this line in the
> feature.xml is valid if the installation context matches these criteria".
>  Currently the set of selectors is pretty limited but there are good
> usecases for extending this and allowing arbitrary selection.

Agreed; but see my earlier point re; OSGi selectors in Require-Bundle.
This would handle the idea nicely.

> - OBR does not address the all problems solved by features.

I didn't mean to suggest that OBR was perfect, but what I'm really
interested in here is the set of problems that aren't solved by using
an external dependency notation.

> - the .eclipseextension files, eclipse dirs, ... etc. are goofy but have
> nothing to do with features, atoms, bundles, ...  We could simply delete the
> check with no loss of generality.

The problem with extension locations is because they partition the
world into 'features' and 'plugins', an extension location has to be
*two* directories. Because of that, they have to be in a directory
called 'eclipse' to bundle the two together.

If there were no separate concept as directories storing the features,
then it wouldn't matter what the directory was called; that, in turn,
would allow you to have a filing structure like
/usr/local/gef/org.eclipse.gef.ui_3.2.0.jar (and other bundles
directly in /usr/local/gef)

I don't see how you'd do that whilst features still exist?

> Having said all that, there are some excellent usecases/motivations for
> simplifying things and increasing consistency in the implementation.
> Personally I'd like to step back from many of these details and get to a
> place where you can have Atom feeds, Dejan can have features (cause he loves
> them so), MEG-heads can have deployment packages, ... all on the same
> infrastructure.  In the end there are wads and collections of wads.  The
> rest is syntax and policy (just for Pascal ;-)

I don't have a problem with the logical concept of features; I do have
a problem with the arbitrary split that Eclipse has between storing
stuff in a 'features/' directory and in a 'plugins/' directory. I can
happily delete everything in my features/ directory in an Eclipse
install, and I suffer no loss of function. If I have a mechanism which
can update a single bundle, a small set of dependent bundles, or a
large set of independent bundles (either service-dependences like the
help server or logical groupings like JDT and CDT) then I don't need
features either.

Lastly, I'd like to observe that we currently do have a bundle for
every feature; in fact, when you want to have language files or
copyright notices for a feature, they are stored in a companion
bundle. So what I'm really proposing is pushing the content in the
features/ directory into those bundles, and just having an update
manager concerned with the storage of bundles. Meta-information -- be
it atom feeds or feature.xml -- can be housed in the feature-bundle
and extracted when installed onto a remote server. I see no reason why
this couldn't be backwardly compatible with other people's features on
the server side.

(Oh, and another reason why features are bad; there's no way of saying
'this bundle should be unpacked' or 'this bundle shouldn't be
unpacked' outside of a feature. That should really be a part of the
Manifest.mf so that an update manager can decide what's right for a
bundle rather than a feature dictating it)

Alex.