[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] Update sites and Builds
|
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
