Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: Re: [platform-update-dev] Investigating some alternative update manager


Alex Blewitt wrote on 09/15/2006 03:47:51 AM:

> On 15/09/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> > - bundle dependencies as expressed in the manifest.mf are not enough for
> > provisioning.  The help system is illustrative here...
>
> 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.

This certainly is one way to go.  My concern is the mixing of concerns :-)  Bundle dependencies have runtime implications (e.g., define the classpath).  in the case described here, there is no real runtime relationship between help.server and help (for example).  At least not at the OSGi, classpath level.  So what we are doing is shoe-horning one set of dependency definitions into a dependency mechanism intended for a different purpose.  The kicker is that 80% of the time the dependencies are the same.  Nevertheless, we are mixing concerns.

> 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.

Can you give an example of how you see Require-Bundle being used for this?  It currently has no selection capabilities of this nature.

> 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.)

Ok, you are going to have to give some concrete examples of the Atom stuff.  Can you create a setup and put it on a server or in a zip file in a bug report or something?  I'm not disagreeing but really need to have it made concrete.  I'd like to see how versions of feeds etc are handled as well.

> (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)

This is not the fault of features or UM.  This is my fault! It may have been a mistake but the thinking was that producers of bundles were not the right ones to say how the bundle should be installed.  In retrospect, most of the time that people mess with this it is because the bundle has an actual technical requirement to be installed as dir rather than a JAR.  Perhaps bundles could/should be able to say how they should be installed...

Jeff

Back to the top