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
