Skip to main content

[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 ;)

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

_______________________________________________
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



Back to the top