uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <pklu...@uni-wuerzburg.de>
Subject Re: Design of p2 version of Eclipse update site
Date Wed, 09 Jan 2013 18:25:05 GMT
Sounds right to me :-)

nice summary btw


Am 09.01.2013 18:27, schrieb Marshall Schor:
> I'm working through issues around the P2 update site.
> We have several projects that use Eclipse features and their associated plugins:
> uimaj-sdk: the set of basic plugins, like the Component Descriptor Editor, the
> Pear packager, the Eclipse Debug support, base runtime, etc.
> uima-as: adds support for the deployment descriptor to the Component Descriptor
> Editor
> cas-editor
> textmarker
> ----------
> The Update site manages various versions of these, and also supplies a top level
> "categorization" of these.  The categorization is supplied (currently) in the
> top level "site.xml" file.  When we move to P2, this ought to be provided by the
> category.xml file (there's an editor in Eclipse to create / maintain this).
> We currently are using the categories:
> uima-tooling-and-runtimes
> uima-as-tooling
> See the very bottom of the site.xml file in the uimaj-eclipse-update-site project.
> We are considering an approach which has multiple update sites, bound together
> by one top-level aggregate update site.  This site would merely list the
> sub-sites; the Eclipse (P2) install support would read this, find the sub-sites,
> read them, and aggregate all of this into a seamless set of menus, as if all of
> these sub-sites had been put together.
> The reasons for going in this direction are, I think, mainly to improve future
> maintenance.  For example, to update the textmarker, only that sub-site would
> need updating.
> The subsites would (most likely) just be subdirectories of the published
> composite update site.
> The "categories" can be cross-cutting, across sub-update-sites.  For instance,
> if we continue to have the category uima-tooling-and-runtimes then a
> sub-update-site might categorize some of its features here.
> --------
> Given that Eclipse has had support for P2 install formats since 2008, I'm in
> favor of converting our build of the update site to be exclusively the P2
> format.  This means we won't have the site.xml or digest.zip files in our update
> site.  I think this would be also a requirement of going with the composite
> update site, as I believe the support for composite sites is part of the P2
> support.  (Also, I note that the Eclipse tooling to support building the
> digest.zip, is no longer part of current
> Eclipse releases.)
> Any feedback from the interested parties appreciated, especially corrections to
> my potential misunderstanding(s).
> I plan to update our svn trunks as follows:
> 1) convert the uimaj-eclipse-update-site to build a "subsite" for the composite
> site, in the P2 style.  This will involve changing the build steps to use the p2
> style Ant tasks, as pioneered by Peter :-)
> 2) move the eclipse-packagings project to the
> builds/trunk/eclipse-composite-update-site.  Updates to this would only be
> needed when the composite structure is changed.  I'll update this to reference
> two sub-update-sites - the uimaj-eclipse-update-site, and a (new) update site
> for the uima-as project.  I would expect that textmarker would be a third update
> site that would be added.
> 3) change the uima-as project to add a new update site for it, which will "add"
> the deployment editor feature, in the P2 form.
> 4) update the build/parent-pom to change the update site build to use the new P2
> tooling.
> Does this sound right?
> -Marshall

View raw message