[eclipse-dev] Fw: Eclipse 3.3 draft milestone plan; features/plugins, up

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Forwarding to the list...

---------- Forwarded message ----------
From: Alex Blewitt <alex.blewitt@xxxxxxxxx>
Date: 17-Aug-2006 18:42
Subject: Eclipse 3.3 draft milestone plan; features/plugins, update
manager, and bundle organisation
To: eclipse-dev@xxxxxxxxxxx


Having looked through the Eclipse 3.3 draft plan
(http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html)
I didn't see three items that I'd particularly like to be addressed in
the 3.3 timeframe.

Firstly, I think that it would be good to migrate 'features' from
top-level components into an extension point provided by a bundle. The
application can still talk in terms of features and plugins, but under
the hood, a feature and plugin would be indistinguishable from one
another. Realistically, a feature doesn't contain much more
information that would be available in a Bundle's manifest (e.g.
dependencies, naming, version, update URLs). Enabling and disabling a
feature would then be akin to starting or stopping that
feature-bundle.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=126732).

This kind of change is only going to happen at the start of a release,
because it may well have a number of impacts. (There would need to be
some kind of migration for existing features, for a start.) But once
it's made, it makes a number of other things possible, such as
reorganising the layout of the Eclipse structure, and allowing a
number of directories to contain bundles instead of just the plugins/
directory. For example, at the moment, an extension location must be
called 'eclipse' and have a 'eclipse/features' and 'eclipse/plugins'
directory. Get rid of features, and you could just have any directory
that you like added that contained bundles/jars. It might even be
possible to start up Eclipse with a command-line of such extension
locations e.g. -bundlepath /a/b;/c/d;e;f. This may be useful for other
Equnox installs, too.

Secondly, the update manager is in need of some work (which is on
there already). One of those is to use individual atom feed to
distribute updates, instead of having a big site.xml to serve
everything. One reason for using Atom feeds is that they're well set
up to send arbitrary information (the payload of an Atom feed has a
mime type, and any mime type can be used in the body, though text and
xml make the most sense). Also, Atom feeds have well defined entries
for metadata such as title, copyright, date created, date updated,
self-referential links etc. Reusing this format whilst putting
Eclipse-specific metadata in the body (e.g. content of Manifest.mf, or
an XML variant of the same) would make it easy for the information to
be encoded. It should also be possible to serve the content (if
suitably XML encoded) via an ordinary feed using namespaces to
separate out the Eclipse from the non-Eclipse content.

The main reason for suggesting this is that it would be possible to
write update 'sites' (atom feeds) for individual plugins. An update
manager could then look for updates to individual plugins, rather than
using the feature as an update point. (Another way of looking at this
is that in effect, each plugin becomes its own mini feature, and has
its own update site.) Of course, not every plugin would have its own
update feed, but atom entries can be combined into a single atom feed,
so it's quite likely that there would be a Manifest->atom entry
translator, and then that atom entry would be combined with others
into an atom feed. This would be backwardly compatible with the update
site mechanism, since each top-level-feature just becomes an atom feed
(and it would be relatively easy to write translators to/from both
inputs, since they're both XML).
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=127236)

(As an aside, the Manifest should be amended to say whether or not the
plugin should be expanded as a directory, rather than the feature
suggesting this. If we can influence the OSGi V5 spec to have a
standard header, that would be good; otherwise, using an
Eclipse-UnpackBundle: true/false would be a good thing to do. That
would seem to be an obvious addition to the UM if features were folded
into bundles.)

Lastly, the PDE does some weird things with running bundles and
classpaths. Unlike other Java projects, the PDE doesn't consult the
output locations (e.g. bin/ or classes/ or Build/ or whatever you call
the output location(s)) for resources, but looks from the root of the
project. This doesn't gel well with automated build projects that
partition the resources and source into different directories. Maven
is the obvious example, but even Eclipse Java projects suggest a
separation of src/ and bin/, and other projects (e.g. Apache Harmony)
have a directory layout that separates resources and source files (and
even have resources for testing purposes).

(See the message thread
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01272.html for
more information on this.)

Unfortunately, PDE and the build scripts expect the manifest to be
rooted under the root of the project, regardless of where the output
folders are. It would seem a small change to be able to modify the
location of the META-INF/MANIFEST.MF to reside under one of the
project's output locations (copied there from one of the project's
source folders, as is currently done for all other resources in all
other Java projects). Unfortunately, it's then a massive task rolling
out that change and getting everyone who expects the
META-INF/MANIFEST.MF to be in the right place as well as the build
locations :-)

It would also clean up a lot of the export problems, since you'd
essentially just be exporting the contents of the build locations.
That would allow you to have (for example) resources/icons/splash.bmp,
but copied into the output bundle as icons/splash.bmp. At present,
there's no way of specifying this in the bundle builder; it copies
everything rooted from the project's top level directory. (I couldn't
find a bug report for this feature, despite it being suggested, so I
wonder if Jeff or Pascal knows about the bug that refers to the
resoruces living in arbitrary directories, or if it was raised at
all?)

These seem to be fairly big changes, and therefore only stand a chance
of getting resolved if planned early enough during an Eclipse cycle.
Also, there will be a reasonable amount of work involved in supporting
older plugins, which will require testing during the Eclipse cycle.
(It might even be deemed too big for the 3.3 cyle, and have to wait
until the 4.x cycle ...)

Is there any chance of these being considered for the 3.3 plan? I'd
personally be interested in helping out with the update manager/atom
feed, but my available time is quite limited these days :-/

Alex.