Re: [platform-update-dev] Scenarios for update manager

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

Just a few things from the top of my
head on what an UM would need (it is complementary):

pluggable transport (ftp, http, ...)
predictability before downloading the
actual bytes
complete update (exes, startup.jar,
etc...)
lay down other stuffs than bundles 
update what has been delivered with
jnlp
update a non running system (manage
multiple configurations)
translatable metadata
flexible configurability (be able to
set start levels, auto start, ini file content)
extensible metadata
transparent support for mirrors
play nice with other provisionning technologies

shared pool of plugins
grouping mechanism with open ended filters
ability to rollback
ability to distribute partial updates
be a platform not a closed product

"Alex Blewitt" <alex.blewitt@xxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

09/19/2006 07:33 PM

Please respond to
"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	[platform-update-dev] Scenarios for update manager

I've been thinking about some of the scenarios that
should be possible
with the update manager:

1) Update a single bundle on its own; for example, org.junit_3.8.0.jar
to org.junit_3.8.1. Note that each version should be capable of being
expanded independently; 3.8 might be a packed Jar, whilst 3.8.1 might
be an unpacked Jar.

2) Updating a single bundle (plus fragments); for example,
org.eclipse.swt. In this case, as well as org.eclipse.swt, we also
need org.eclipse.swt.win32.win32.x86 to be updated as well (c.f. mac,
linux etc.). Note that an update dependency between bundle and
fragment will be in the opposite direction to the OSGi concept of
dependencies, in that updating org.eclipse.swt will depend on updating
org.eclipse.swt.win32... It will therefore be quite likely that update
metadata will end up containing dependencies from org.eclipse.swt to
all fragments on various os combinations, and that some fragments may
have to be selected on the basis of os/ws/arch selectors

3) Updating items atomically. For example, it doesn't make sense to
update org.eclipse.swt without updating the fragments. (If
org.eclipse.swt is a wad, and org.eclipse.swt.win32... is a wad, then
an atomic update to this lot is awad?).

4) Updating dependent bundles; for example, org.apache.xalan and
org.apache.xerces. Updating the xalan wad should be dependent on
having (or updating) the xerces wad. Furthermore, there may be
versioning/runtime constraints on the xalan wad that needs a
particular minimal version of xerces in order to run. It should be
possible to determine (prior to downloading any wads) that updated
version(s) of xalan or xerces are available; and in particular, even
if the user just selects to update xalan from the UI, the dependencies
are also checked for updates. If xalan+1 can run on xerces, then
updating xerces is optional. If xalan+1 needs xerces+1, then xerces+1
must be updated prior to or at the same time as xalan+1.

5) Updating independent bundles; for example, org.eclipse.help,
org.eclipse.help.ui, org.eclipse.help.appserver. In this case, the
bundles are not runtime dependent on each other, but are grouped in
such a way as to be an awad. (The same also applies for services and
clients wishing to utilise those services.)

6) It should be possible to obtain update metadata from the bundle,
either by extracting a suitable manifest file (for example,
META-INF/UPDATE.XML) or by decoding from appropriate manifest entries
in the MANIFEST.MF itself. However, given a bundle in isolation, it
should be possible to derive the wad update information in order to
update it individually.

7) Note that for nested updates (e.g. xalan/xerces) not all the
information needs to be present about the dependencies other than they
are required. So a xalan UPDATE.XML will have detailed information
about where to acquire updates for xalan+1, but only express
requirements about xerces+1 -- the update manager should be
responsible for finding the update information about xerces+1. This
allows the process to scale, such that each bundle knows its direct
dependencies, but delegates the locating of those dependencies to the
updating process

8) It should be possible to use these same technqiues to represent a
set of unrelated bundles as an awad, or as a set of wads. Even though
there may be no direct runtime relations between them, they may be
grouped in such a way to serve a particular purpose (e.g. to represent
the RCP platform as a whole) However, the same process should be used
for a single bundle as for many tens or hundreds of bundles

9) Wad dependencies should be mandatory or optional, as well as having
version constraints os/ws/arch constraints (or using OSGi filter
constraints if necessary). A UM should give the user the option of
downloading the optional requirements, which may include things like
help, source code, optional Ant tasks etc.

10) The PDE should be able to assist generation of the UPDATE.XML (or
equivalent) via the editors. Where possible/practical, the UPDATE.XML
information may be (initially) derived from the entries in e.g.
Require-Bundle or Bundle-Name, but will likely have its own entries
and ways of storing this information. The point is that the default
data should be computed where possible from existing information, but
that it can be overridden easily and additional data added or removed.
Given that e.g. for fragments the dependency is in the wrong
direction, or in the case of independent bundles like help, it is
unlikely that Require-Bundle may be useful all the time; but in the
majority of 'simple' cases, it could be. Note also that current
mechanisms e.g. PDE's "Validate required plugin set" and "Add
required
plugins" could be utilised to help create such information.

11) The UPDATE.XML metadata should be downloadable independently from
a bundle itself. This will allow a fast set of downloads to validate
required update(s) before any data is downloaded. To ensure a mapping
between the UPDATE.XML and the bundle itself, some common naming
convention should be used (e.g. com.example_1.2.3.jar --
com.example_1.2.3.UPDATE.XML)

12) The UPDATE.XML metadata should be extractable programmatically
from a bundle; either by simple file extraction (jar xf
META-INF/UPDATE.XML) or some simple processing. Thus, a
website/repository of bundles should be able to be
manipulated/organised by file-based tools, and for simple cases,
without needing to do anything else.

13) The UPDATE.XML files for individual (a)wads should be able to be
collected into cwads. These should be nestable, so that a cwad for RCP
Platform consisted of e.g. cwads for JFace+SWT, and cwads for
Platform/Equinox, which in turn consist of cwads for the individual
wads being updated. It is possible that a cwad's UPDATE.XML will
contain multiple versions of the same bundle; ergo, one of the
important entries in the UPDATE.XML will be the bundle identifier and
version information. It may be possible for the UPDATE.XML to
associate tags or other identifiers with the individual entries, so
that (for example) a cwad could point to the HEAD, NIGHTLY,
INTEGRATION, STABLE and RELEASE wads. (A suitable filter, based on
input from the UM, would be used to select the appropriate flavour
here. However, this is an example of something for the future rather
than a hard requirement here.)

14) The UPDATE.XML should contain the following information: the name
of the bundle; the version of the bundle; the os/ws/arch (if
appropriate); a URL to the actual bundle Jar; whether it should be
unpacked or not; a list of dependencies to other bundles/fragments
(with optional version, os/ws/arch constraints, optional/mandatory);
the URL of the UPDATE.XML file itself (so that when deriving it from
an existing bundle on a disk, you know where to update it from); the
date it was updated/created; copyright information; licence
information; textual description;release notes. Note that URLs might
be subject to rewriting to obtain a closer mirror, or an internal
mirror etc, and that descriptions might either be in-line or URLs to
external sources. Some of this information could be directly derived
from existing Bundle headers (e.g. Bundle-Copyright, Bundle-Category)
if required.

I expect that once the dependencies are defined at the individual
bundle level, then there may be many arrangements that one could make
from the appropriate UPDATE.XML entries. For example, a Platform/RCP
could be generated from all the bundles in the platform, or a
JFace+SWT could be generated from just the JFace and SWT bundles. It
should also be easy for third party developers to declare dependencies
on these bundles; so com.example.foobar could depend on the JFace+SWT
updates by simply linking an appropriate UPDATE.XML to include
pointers to those bundles. Certainly, I could see the feature.xml
being an example of a top-level UPDATE.XML with individual entries for
bundles looking very much like mini-features of their own (although
probably not to the level of being an IFeature in Eclipse itself).
Ideally, creating an update mechanism for a single bundle should be
just as easy as creating an update mechanism for a suite of bundles.

I've used the term UPDATE.XML here as a moniker for the update
metadata. It might not be in an XML format (e.g. extra entries in the
Manifest) or it might be an XML document (much like the feature is
today). I still strongly think that if an XML format is used that the
outer wrapper be an Atom entry; though, as I've noted before, this
gives complete freedom to the payload(s) carried internally.

I'll start thinking of what this could look like, but I wondered if
I've missed any scenarios or desirable (ahem) features that the update
manager could need under the covers?

Alex.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev