Community
Participate
Working Groups
This came up at EclipseCon as a must-do for Athena - everyone wants product builds! Not sure what's involved here, but I suspect we'd need to feed in a .project file and some other meta, in order to generate platform-specific binaries instead of the all-in-one zips we already support. Marking this one helpwanted because product builds are as yet out of my realm of expertise.
I think there is a bit of overlap with the EPP project, which provides a way to build applications by desribing them as a set of features using update-sites. The steps could "simply" be to produce an update-site from the features, and then to build some applications on it using EPP...
(In reply to comment #1) > I think there is a bit of overlap with the EPP project, which provides a way to > build applications by desribing them as a set of features using update-sites. > The steps could "simply" be to produce an update-site from the features, and > then to build some applications on it using EPP... Frankly, I'd prefer if Athena and EPP would work together such that the output of Athena is a zipped p2 repo, and that can be input to EPP. I don't want to duplicate work if it's already solved in EPP. This bug is therefore about integrating EPP and Athena, so that a product can be produced as easily as possible. This is probably a dumb question, but how does an EPP specfile like https://bugs.eclipse.org/bugs/attachment.cgi?id=128541 get turned into EPP bundles? And can such a file support the input of packed update sites, or would scripting be required to take the archived p2 repo output from Athena and unpack it for inclusion in an EPP build? (Wiki links are sufficient, I'm just too tired atm to go hunting for a 'getting started w/ EPP' guide.)
I also think that getting Athena and EPP to collaborate on the "easiest way" to create a product would be a good thing. Then I added EPP packager bugs mailing list to the CC. AFAIK, the easiest way to start an EPP assembly is to: * Get all platform-specific Eclipse platforms in a folder wherever on your local filesystem. (eclipse-platform-...-linux-gtk-x86, win32-win32-x86 and son on) * Get a working instance of Eclipse with plugin "org.eclipse.epp.packaging.core" installed (I could only get it by checkout-ing it in my workspace) * Write a epp package config file. * And then run the packager application: ${LAUNCHER_JAR} -data <workspace> -application org.eclipse.epp.packaging.core.application <path_to_config_file> I think it is all. But beware that the build is not very fast (it is several dozens of minutes for my current tests for the "standard" 4 target platforms).
Instead of using the packager, you can generate the metadata from source and then run a product build for the final results. See "Build integration with p2" under http://download.eclipse.org/eclipse/downloads/drops/S-3.5M6-200903130100/eclipse-news-M6.html#PDE and http://aniefer.blogspot.com/2009/03/building-p2-rcp-products-in-eclipse.html This has much better performance than using the packager :-)
(In reply to comment #4) > Instead of using the packager, you can generate the metadata from source and > then run a product build for the final results. So... the feature build will produce update jars and p2 metadata. Great. Then we send it off for signing, retrieve it when done, and pack200 it up. At that point, I have to regenerate the metadata because the jars have changed (size, contents) and there are now packed versions to which the metadata can now refer. How does pregenerating the metadata help me, if it's incorrect by the time I've signed & packed? (Or have I missed something here?)
You can run the product build and send the resulting repository off for signing. Then pack the results, then run the "p2.process.artifacts" ant task which will update the artifact metadata with the changed MD5s and add the pack.gz descriptors. Set "skipDirector=true" (starting with this week's IBuild, see bug 271141) to skip doing the product installs before the signing/packing. Then run director calls afterwards to get installed zips.
(In reply to comment #6) > You can run the product build and send the resulting repository off for > signing. > Then pack the results, then run the "p2.process.artifacts" ant task which will > update the artifact metadata with the changed MD5s and add the pack.gz > descriptors. > Set "skipDirector=true" (starting with this week's IBuild, see bug 271141) to > skip doing the product installs before the signing/packing. Then run director > calls afterwards to get installed zips. So, for feature or product builds, the process is therefore: 1. build using p2.gathering=true and skipDirector=true; get Master zip w/ update jars and p2 meta 2. push Master zip to build.eclipse for signing; retrieve zip of signed jars 3. pack200 4. <p2.process.artifacts> to get updated p2 repo archive w/ packed and non-packed jars 5. <p2.director> to produce product zips (p2 repo installed into multiple platform) or project zips (SDK, runtime, etc.) Correct? How do you use the director to provision an SDK or runtime zip? Do you "p2 install" a feature into some temp directory, then zip up that directory?
(In reply to comment #7) > So, for feature or product builds, the process is therefore: > > 1. build using p2.gathering=true and skipDirector=true; get Master zip w/ > update jars and p2 meta > > 2. push Master zip to build.eclipse for signing; retrieve zip of signed jars > > 3. pack200 > > 4. <p2.process.artifacts> to get updated p2 repo archive w/ packed and > non-packed jars > > 5. <p2.director> to produce product zips (p2 repo installed into multiple > platform) or project zips (SDK, runtime, etc.) (4) is capable of doing (3), these can be one step: <p2.process.artifacts repositoryPath="file:/build/unzippedMaster" pack="true" /> (it can also do signing) > > How do you use the director to provision an SDK or runtime zip? Do you "p2 > install" a feature into some temp directory, then zip up that directory? Basically, yes. As an example of running the director, you could look at org.eclipse.releng.eclipsebuilder/equinox/buildConfigs/equinox.prov/run.xml which has a run.director task and many calls to it. For a product build, you could also try calling the generated package.<feature>.<config>.xml scripts a second time without skipDirector set which would do this for you.
Nick, what's the current status of this bug?
(In reply to comment #9) > Nick, what's the current status of this bug? Waiting for a patch or a demo. Are you offering to lead this work? Eclipse wants you, remember? :) https://bugs.eclipse.org/bugs/attachment.cgi?id=102974
This won't get done. If you want a simple build of Eclipse products, features, plugins, or update sites / p2 repos, using CVS, SVN, Git, or any other Hudson-supported VCS/DVCS... I recommend using Tycho, which supports it natively. https://docs.sonatype.org/display/TYCHO/How+to+run+SWTBot+tests+with+Tycho http://anonsvn.jboss.org/repos/jbosstools/trunk/build/parent/pom.xml http://www.delicious.com/nickboldt/tycho https://docs.sonatype.org/display/TYCHO/Tycho+reference+card
