[cross-project-issues-dev] Galileo delivery

[Richard Gronback <richard.gronback@xxxxxxxxxxx>]

Title: Galileo delivery

Hello,

Note: discussion on this thread should take place within the context of bug: http://bugs.eclipse.org/250745

The Planning Council has been discussing the delivery of Galileo [1]; specifically, whether or not we'll have a common update site as we did for Ganymede that copies each project's jar files.  I've come up with an approach that I think will work for Galileo that leverages p2, but wanted to broaden the discussion to those who know more than I, just to make sure I'm not missing something obvious or there's a better approach to consider.  Sorry for the uncharacteristic verbosity to follow...

In the Modeling Amalgamation Project [2], I've been playing with product-based build configurations that produce downloads to target different modeling audiences.  Having previously developed/maintained the GMF project's build scripts, I decided this time to keep things as simple as possible and generate what I could from a simple model.  The Eclipse .product definition model provides most of what I needed and comes with a nice editor and build integration.  I created a product.ecore EMF model that matches the provided product definition model and augmented it with a build.ecore EMF model that contains the missing pieces required to generate the build scripts (based on [3]) using some simple Xpand model-to-text templates.  Yeah, I know... “modeling guys!” but it’s really quite simple.

The generated build scripts go through the usual steps of configuring a target with delta pack, using the p2.director to install each feature by version listed in the .product definition from its repository location referenced in the corresponding .build model.  Then, the build of the Galileo feature/plugin takes place, followed by the usual product packaging.  Finally, the p2.director is run again to produce each of the specified platform product archive.

As I see it, there are several advantages to having a galileo.product definition and corresponding headless p2-ified PDE build script:

1. A p2 content.xml and artifacts.xml repository files are generated during the process, which can be published as a common repository for all of Galileo.  Source repository references are included, making the copying of each project jar files unnecessary (requires confirmation... Anyone?).
2. The jar files are actually assembled during the process, which may allow EPP packages and forthcoming "custom installer" to function easier, even if the site is not exposed to the community.  Or, it just becomes a single repository not unlike what we did for Ganymede.  I haven’t yet looked into how to categorize the content, so pointers would be appreciated.
3. The use of a .product definition means we can brand Galileo separately from the Eclipse SDK.  So, a custom splash, Welcome, About, etc. can be provided if desired.
4. The resulting product build provides an all-in-one download for those who interested in such a (huge) thing.

As I see it, we can replace the maintenance of individual project .sc files we used with Ganymede with a single galileo.product file and corresponding galileo.build model (for repository locations, base configuration info, etc. which is all fairly static).  A simple CruiseControl project can sense changes in these files, regenerate and build automatically, or be run explicitly for each milestone/release.  It seems like a reinvention of what Buckminster and even EPP does, but I’m not sure of their p2-ification.  And, it just seemed like the simplest solution for me at the time.

Let the discussion begin.  If it turns out this is a viable approach, I'm willing to continue developing and maintain this for Galileo, although I'd certainly appreciate help from our former [David|Bjorn|Gany]-o-matic experts, not to mention p2 team ;)  I also think the approach of model-driven builds has advantages that Bjorn et al may find interesting for the common build infrastructure effort.

Thanks,
Rich


[1] http://wiki.eclipse.org/index.php/Planning_Council 
[2] http://www.eclipse.org/modeling/amalgam/downloads/
[3] http://aniefer.blogspot.com/2008/06/example-headless-build-for-rcp-product.html