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

So there's an intersection. But I believe that in the general OSGi
case; anything that you need on the path at run-time is a superset of
those that you need at compile-time (as the 'builders' take care of
that in the Eclipse PDE/JDT world). Therefore, going back to the help
example, a feature will define what it needs at run-time (help+help
server) which is a superset of those that are needed at compile-time
(help pages).

In any case, the bundle dependency is that; the dependencies needed
for this bundle to 'work'. In the case of a help-bundle-feature, it
could depend on the help UI and the help server.


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

So the help-featurette-bundle would just contain a resource -- like
'feature.xml' -- that could be interrogated by the IFeatureProvider
(or the interface mentioned yesterday). The fact that it doesn't add
any classes isn't spectacularly relevant IMNSHO. Surely bundles are
more about defining modules that have defined (and versioned)
dependencies? They're not 'modules of classes', though they can
contain them -- they're modules that contain classes and resources.
Just because the class count is zero, doesn't make it any less of a
bundle that has dependencies.


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?


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


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

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.


I think there are these kind of things that need to be fleshed out :-)
But I have already raised the bug with a pseudo-example:

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="http://update.eclipse.org/updates32/"/>
 <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="http://www.eclipse.org/news/2006/02/08/wtp/1.0"/>
   <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="http://downloads.eclipse.org/plugin/org.eclipse.wtp_1.0.0.jar";
     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).

The point is that the atom feed itself is a wrapper that contains
dated, specific nuggets of information; but that information can be in
any format you chose. The 'eclipse:plugin' here (bundle would perhaps
be more appropriate) was more of a fill-in-the-blank-here than
I-have-thought-about-this-in-depth ... heck, you could even use the
same DTD that's present for the site.xml and embed it in an atom feed
:-)


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


I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=157562 to
request the addition of an Equinox-Unpack attribute in the manifest
header. It's currently associated with the Equinox project; it may be
better to move that elsewhere. I've also described the semantics; it
defaults to false, if it's not present, and a feature requires it to
be unpacked, then it will; if it's present either unpack it (true) or
not (false) and takes priority over a feature. That would give it
backward compatibility with what's there at present, but defines
semantics going forward (and ones that need it e.g. the help server
could define Equinox-Unpack: true). Once those semantics are agreed,
UM2 could utilise that to drive whether to unpack a bundle or not.

Alex.

Back to the top