Skip to main content

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


Alex Blewitt wrote on 09/16/2006 04:52:05 AM:

> On 16/09/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> > Alex Blewitt wrote on 09/15/2006 03:47:51 AM:
> >
> >  > 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 :-)
>
> True, one is used for runtime dependencies, and the other is used for
> expressing requirements. But you have that in a number of other
> places, too e.g. Maven POMs. Recently, they changed the POM definition
> to represent differences between:
>
> 1) Dependencies needed at compile time and at run-time (e.g. xerces)
> 2) Dependences needed at compile time by not run-time (e.g. Jibx
> compiler; needed to translate Jibx schemas into classes)
> 3) Dependencies needed at run-time but not compile time (e.g. JDBC drivers)

Not too familiar with Maven POMs but if I understand, you are pointing out that in fact the Maven folks have choosen to distinguish between the different types of dependencies.  I understood you previously to be saying that we could just lump this all together in Require-Bundle.  That is the mixing of concerns to which I was refering.

> > 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.
>
> It's a logical dependency, not a classpath one; indeed, the
> help-featurette would be unlikely to have classes anyway. But there
> are bundles that also fit this role in the current SDK; for example,
> the 'source' plugins that are provided have no classes and therefore
> add no value in that sense either. A bundle may be present for the
> provision of resources; the help documentation is such a resource
> (there's no classes AFAIK in the jdt.help; yet, the help server can
> interrogate any jdt.help or cdt.help plugins to display information).

Yes, Require-Bundle can be used to express arbitrary dependencies.  This works well as long as there are no clashes with other types of dependencies (e.g., the classpath).  Since, as you point out, source and help content plugins don't generally have code, they are not really at issue.  If Require-Bundle is the mechanism used to express logical grouping, how do I group things and NOT have them added to my classpath?  This is the mixing to which I was refering.

Side clarification 1:  Source bundles to not have Require-Bundle headers at all (see your example below).
Side clarification 2:  It is useful to distinguish between "resources" and "entries" (or "files") supplied by a bundle.  Resources are things that are discovered by a classloader looking on a classpath.  Entries or files are bundle content that is accessed via Bundle.getEntry() and friends.  As such, resource discovery and loading is impacted by dependency declarations while entry access is not.

> > 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.
>
> I think that the confusion is related to the unstated assumption that
> all bundles need classes. For example, here's the bundle taht contains
> platform-source:
>
> Manifest-Version: 1.0
> Bundle-Name: %pluginName
> Bundle-SymbolicName: org.eclipse.platform.source; singleton=true
> Bundle-Version: 3.2.0.v20060609m-AgOexn6hlEUsvBO
> Bundle-Localization: plugin
> Bundle-Vendor: %providerName
>
> See? No Bundle-Classpath. It's not essential. Why can't it have
> Bundle-Requires, but not Bundle-Classpath? Is there anything in the
> OSGi spec that demands it?

I don't think there is any confusion or assumption that bundles need to contain code.
Side clarification 3:  ALL bundles have a Bundle-Classpath whether they want one or not.  The absence of the explicit header implies a classpath of '.' or the entire content of the bundle.

> > Can you give an example of how you see Require-Bundle being used for this?
> > It currently has no selection capabilities of this nature.
>
> I was referring to the Filter Syntax of section 3.2.6 of the OSGi_R4
> specification, and the example used in the spec is:
>
> Bundle-NativeCode: lib/http.dll ; lib/zlib.dll ;
> osname = Windows95 ;
> osname = Windows98 ;
> osname = WindowsNT ;
> processor = x86 ;
> selection-filter=
> "(org.osgi.framework.windowing.system=win32)";
> language = en ;
> language = se ,
>
> Of course, there isn't such a selector on the Require-Bundle at the
> moment :-) That's why I was bringing it up as a topic for discussion;

Using LDAP filters is problematic as they are not declarative.  The only thing you can do with a filter is run it in a context.  You cannot, in general, reason about it and, say, discover the set of characteristics needed to satisfy the filter.  Of course, you can poke around for well known keys and start parsing the logic but that is challenging.  We may end up doing that kind of thing but not if we can avoid it.

> it could be done by e.g. Eclipse-AlsoNeeds: -- but if you're adding a
> new header, then the issues wrt the Require-Bundle: may go away?

The discussion around the syntax of the dependency information is somewhat premature IMHO.  The jist of your argument is that "provisioning dependency" (for lack of a better term) information can/should be included in bundles rather than features.  This is, for the most part, is fine with me but more thinking/kicking is needed.

We should separate that discussion from the syntax/location discussion since.  Without the separation, one's objection to relying on Require-Bundle for this provisioning information could be construed as an objection to putting that information in bundles.  

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=127236; but, for
> completeness, here it is:
>
> <?xml version="1.0" encoding="utf-8"?>
> <feed xmlns="http://www.w3.org/2005/Atom"
> xmlns:eclipse="http://www.eclipse.org/">
>   <title>WTP Updates</title>
>   <link href=""> >   <updated>2006-02-08T09:00:00Z</updated>
>   <author>
>     <name>Eclipse foundation</name>
>     <url>http://www.eclipse.org</url>
>     <email>wtp@xxxxxxxxxxx</email>
>   </author>
>   <id>urn:uuid:http://www.eclipse.org/wtp/</id>
>   <entry>
>     <title>WTP 1.0 released!</title>
>     <link href=""> >     <id>urn:uuid:http://www.eclipse.org/wtp/1.0</id>
>     <updated>2006-02-08T09:00:00Z</updated>
>     <summary>The latest and greatest is now available for download
> ...</summary>
>     <eclipse:plugin
>       name="org.eclipse.wtp"
>       version="1.0.0"
>       url=""> >       torrent="http://www.ibiblio.org/eclipse/org.eclipse.wtp_1.0.0.torrent"
>     />
>   </entry>
> </feed>
>
> Of course, this doesn't contain any of your issues like how
> dependencies would be handled or whatever ... I'll work on a more
> detailed example this week and add it to it. (By the way, although
> this example doesn't show it directly, the XML elements are all in
> namespaces, so having atom:feed etc. is possible if there isn't a
> default namespace).

I look forward to seeing a complete example.

Jeff

Back to the top