Re: [bpel-dev] Update sites and Builds

[Vincent Zurczak <vincent.zurczak@xxxxxxxxxxxxxx>]

Le 05/04/2012 17:49, Mickael Istria a écrit :
> > Actually, we are in version 0.8.0 (the Hudson job should be renamed).
> > OK for the promotion mechanism. But we have to do it manually, right? 
> > That's fine with me.
> Yes, I think that should be done manually. It is just a copy on 
> download.eclipse.org.
> It always happen that someone has to perform something to do a release 
> (could it be to run a new build with a flag, run a script...), here it 
> is just a copy.

OK.

> > We have one job for Helios (bpel-0.5) and one for Juno (-juno). We 
> > must keep one job per platform to make sure it builds and works.
> Eclipse Platform and the dependency you use guarantee that if you work 
> with Indigo, it should be fine for Juno.
> Maybe we could try to set up a mechanism to build on a Indigo platform 
> and test on a 4.2.

In BPEL, we introduce some flexibility in the dependencies we use.
We cannot guarantee that a dependency's content won't change between 
Helios and June. Besides, we are not entirely on API code (e.g. with 
WTP, so if a WTP bundle changes one class between Helios and Juno, it 
will be broken on one build).
So, we must have a build for Helios and one different for Juno.


> > For the moment, packing and signing is done with Maven, in the Juno 
> > build.
> It could be done in any build, I don't think it will cause troubles.

OK, so we can keep the current solution.

> > What changes do you propose?
> > Which job will pack, sign and publish the snapshot update site?
> bpel-0.8 would produce the repository, test it and publish it to 
> 0.8.0/snapshot. All repositories (including snapshots) would be packed 
> and signed).
> If we want to test against several platforms, we could think about a 
> job that would consume the published site and perform some tests.

Given that we must have 2 different builds, I would rename bpel-0.5 in 
bpel-helios, so that we ensure backward compatiblity of the BPEL Designer.
The produced build is not moved anywhere.

We update the juno build to be launched on every commit (after thinking 
about it, OK for signing and packing it directly, we don't commit that 
often).
The produced build is moved in the /snpashot directory, as you said.

Do you agree?

           Vincent.

--
Vincent Zurczak

RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16