org.eclipse.jst.server.generic.core+\
org.eclipse.wst.ws_core.feature.feature.group+org.eclipse.wst.web_ui.feature.feature.group+org.eclipse.wst.ws_wsdl15.feature.feature.group+\
org.eclipse.wst.xml_ui.feature.feature.group+org.eclipse.wst.common_ui.feature.feature.group+org.eclipse.wst.common_core.feature.feature.group+\
org.eclipse.xsd.feature.group+org.eclipse.gef.feature.group+\
org.eclipse.gmf.runtime.diagram.ui+\
org.eclipse.emf.compare.match+org.eclipse.emf.compare.diff+org.eclipse.emf.compare.ui+\
org.mozilla.xpcom+org.jboss.tools.vpe.resref+org.jboss.tools.jst.web.ui+org.jboss.ide.eclipse.as.core+org.jboss.ide.eclipse.archives.webtools+org.jboss.tools.jmx.feature.feature.group
In this case, even pulling from the Galileo and JBT nightly update
sites, the provisioning step only took 4 minutes (248411 ms).
If you source from locally cached p2 repo zips such as these [2],
it's even faster.
[2]
http://download.eclipse.org/athena/repos/
Nick
David Carver wrote:
There are ways to do this. And you might be able to do it in
your own customTargets.xml file. Basically you would do a two
stage build, either all in one Job or in two separate jobs. The
first one would be to build and create the target platform and
provision it. The second would be to create the necessary
tests, and run them based on the input from the first provisioning.
I've done this in the past by using a combination of the ZIP
files, combining them into a working target platform, and then
deploying the tests and running them. I do agree that the P2
provisioning process seems to take way longer to get setup than
just a straight ZIP provisioning.
The main issue I see right now is that with the P2 director
steps, it is done in a loop, instead of being able to provide a
list of all the items to be provisioned in one provisioning
step. Each plugin or feature is provisioned separately. If
we could find a way to provide a list of items to be provisioned
and have it done in one provisioning step (i.e. not executing P2
director multiple times), I think that alone would go a long way
to speeding up the build.
Also, you may want to look at an alternative cleanUp step if you
have a large directory that is created during the build with
many sub directories. I've found that trying to avoid wildcard
searches and deletions with FileSets greatly speeds up the
deletion and cleanup process.
Nicolas Bros wrote:
In fact, I was not only thinking of re-using the build
target platform for testing, but also re-using a previously
snapshotted build target platform instead of provisioning a
new one for each build. My idea was to be able to skip all
the work done in the "postSetup" target in
customTargets.xml, if nothing changed in the build
configuration since the last build. Would that be doable ?
On Wed, Dec 9, 2009 at 3:24 AM, Nick Boldt
<
nickboldt@xxxxxxxxx <mailto:
nickboldt@xxxxxxxxx>