[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] Update sites and Builds
|
Greetings All
does anyone know whether Apache ode is still on the site because when i tried to download it returns the following error
Cannot complete the install because one or more required items could not be found.
Software being installed: Runtime Adapter for Apache ODE 1.3 0.8.0.v20111109-1901-H94-CI (org.eclipse.bpel.apache.ode.runtime.feature.feature.group 0.8.0.v20111109-1901-H94-CI)
Missing requirement: Runtime Adapter for Apache ODE 1.3 0.8.0.v20111109-1901-H94-CI (org.eclipse.bpel.apache.ode.runtime.feature.feature.group 0.8.0.v20111109-1901-H94-CI) requires 'org.eclipse.wst.server.core [1.1.0,2.0.0)' but it could not be found
Please help
On Fri, Apr 6, 2012 at 12:34 PM, Mickael Istria
<mistria@xxxxxxxxxx> wrote:
On 04/05/2012 06:39 PM, Vincent Zurczak wrote:
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.
Ok. got it: you have only 1 source code, and you want to build and
test it against Helios and 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?
Yes, I think it is fine. I was just worried in the case you were
maintaining 2 branches. But it seems like you have a single branch,
a single publishing build (on Juno) + a validation build against
Helios to ensure backward compatibility. It sounds good to me.
If you need any further help, feel free to ask, I can come by your
office to give a hand ;)
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Name : Mr T. Shezi
NickName : Mthimbanator
Student No : 200702908
Level : Computer Sc Research Student
Institution : University of Zululand
Department : Computer Science
Cell No : 078 706 7208
