[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bpel-dev] Update sites and Builds
- From: Vincent Zurczak <vincent.zurczak@xxxxxxxxxxxxxx>
- Date: Thu, 05 Apr 2012 18:39:50 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
Le 05/04/2012 17:49, Mickael Istria a écrit :
Actually, we are in version 0.8.0 (the Hudson job should be renamed).Yes, I think that should be done manually. It is just a copy on
OK for the promotion mechanism. But we have to do it manually, right?
That's fine with me.
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.
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
It could be done in any build, I don't think it will cause troubles.
OK, so we can keep the current solution.
bpel-0.8 would produce the repository, test it and publish it to
0.8.0/snapshot. All repositories (including snapshots) would be packed
What changes do you propose?
Which job will pack, sign and publish the snapshot update site?
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
The produced build is moved in the /snpashot directory, as you said.
Do you agree?
RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16