project_key: SOA

From Julian Coleman:

I mentioned a few times that I would send a mail around about the branches
and tags that we have in the SOA repository, and also a mail about the
(proposed) new build structure.

SOA branches and tags
---------------------

We have the trunk (head) of development in:

  https://svn.devel.redhat.com/repos/jboss-soa/trunk/

Ideally, we should put changes and run tests here.  When the changes are OK,
we can add them back to the release branches (sometimes called a "pull up" -
as in "to pull up changes to the branch", because the branch is behind the
trunk).  The release branches we have are:

  https://svn.devel.redhat.com/repos/jboss-soa/branches/4.2.0/
  https://svn.devel.redhat.com/repos/jboss-soa/branches/4.3/

for the SOA 4.2 and 4.3 releases, respectively.  (There are also some other
branches in the .../branches directory, but perhaps we should do something
like ESB and create a .../workspace directory for test and development.)

We also now have internal tags under:

  https://svn.devel.redhat.com/repos/jboss-soa/build-team-tags/

For example:

  https://svn.devel.redhat.com/repos/jboss-soa/build-team-tags/SOA-4.2.0.GA_CP04_CR3/

for the 3rd candidate release of 4.2.0 CP04.  (Note that we haven't followed
that for older releases.)

When a release is done, we should also create a tag under:

  https://svn.devel.redhat.com/repos/jboss-soa/release-tags/

For example:

  https://svn.devel.redhat.com/repos/jboss-soa/release-tags/4.2.0.GA_CP04/

for the released version of 4.2.0 CP04.


When we are starting a release, we should send a mail message round (we
need to get better at this).  For example:

  "The SOA 4.2 branch is ready for CP04, please do not commit, as I am
  about to create CR1"

and also mail with changes to status (moving to CR2, etc.)  When we finish
the release, we should also send a message.  I think it would make sense
for a person nominated as "release manager" to make sure that this is done.
(One doesn't have to do everything, but just check that everything is done.)


New build structure
-------------------

The ideas behind changing the build are:

  1) Make the build more modular
  2) Make the build easier to follow
  3) Remove duplicated code
  4) Remove as many external dependencies as possible
  5) Remove binaries from the source repository

To make the build more modular, we should not build jBPM and Drools every
time, but only if they have changed.

To make the build easier to follow, I would like to make it a sequence of
logical steps.  Something like:

  1) fetch		Fetch the source code or binaries
  2) pre-patch		Patch the source before we build
  3) build		Run the build
  4) post-patch		Patch the builds
  5) release		Create the release zips

I'd also like a single build.xml to only deal with one area, so that the
jBPM build.xml only touches jBPM, etc.  One problem is that build involves
taking the results from one build and adding it to another (e.g. jBPM to
ESB) and also the way that the EAP subset is added to the ESB build.  I
think that these operations should be put into the destination builder.
Also, it probably makes sense to do this as a separate stage from the the
above 5 (maybe we could have:

  2.5) assemble		Assemble other components for this build

I've already made a start on removing the duplication in the SVN and the
EAP binaries code and moved that to build-common.xml.  I've also added
comments, so that it should be fairly understandable.

The above is only my thoughts on how we should set things out.  I'd welcome
any suggestions (even ones that say this is all the wrong way of going about
it  ;-) .

Thanks,

J

-- Red Hat Newcastle upon Tyne