| On 04/05/2012 06:39 PM, Vincent Zurczak wrote: 
 
      Ok. got it: you have only 1 source code, and you want to build and
    test it against Helios and Juno
        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.
 
 
 
 
      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.
        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?
          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).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 often).
 The produced build is moved in the /snpashot directory, as you
      said.
 
 Do you agree?
 
 
 If you need any further help, feel free to ask, I can come by your
    office to give a hand ;)
 
 |