On Jan 8, 2007, at 6:01 AM, Kevan Miller wrote:
Are you building openejb by hand, or are the deployed snaps up to
date?
I built OpenEJB locally. Looks like new snaps will need to be
pushed out to pick up David J's changes...
This is one reason why I had chosen before to always build the server
dependencies when I automated builds. This was the reason why I
wanted to build release branches for dependencies, so that the exact
same configuration could be used to handle both SNAPSHOT and release
artifacts.
If you look at this from a build automation perspective, the
configuration of the automation tools really needs to be the same...
and it needs to be able to handle the change of versions from
released to SNAPSHOT as was made here. Building everything from
source is one of the easiest ways to accomplish this and get reliable
builds which don't break so easily when a change like this is made.
BUT, since the OpenEJB branch keeps moving around, and because people
keep telling me that I should just use release artifacts, I had
removed that interim build of OpenEJB to support the automated build
of the server.
If we want to do things the Maven-way, then when any change which
will break compatibility is made on a dependency is made, then that
project *MUST* publish new SNAPSHOTS after it has committed the
change to SVN. Otherwise projects which depend on them will
essentially be broken. I have been doing this with Genesis
regularly, when a change is made that is needed by the server builds,
then I publish the modules that change, so that with a clean repo, or
mvn -U, the build will function as expected.
I *don't* think it is good enough to use an automated nightly to
publish SNAPSHOTS as the only mechanism for this either. I think
that automated nightly deployment is a good stop gab measure to help
catch when people miss a deployed changed... so builds won't be
broken for more than 24 hours when someone does forget. But when
they do forget, the build could be broken for the duration of the day
until automated deploy kicks in which sucks IMO. Build automation
should be the trusted source for the state of the builds... if the
automated build is broke, then the build is broke, if your local
build is broke, but the automated build is fine, then you have an
environmental problem or local code change which has broken your build.
* * *
I believe that this is a critical process which we really need to
help allow our developers to focus on code... and not on the build.
I have been trying to solve this problem for months now... though I
have not been getting much support from the group :-( I almost had
it solved, and then the view of the world changed (the specs release
mess that I was so upset about).
Due to the challenges of using Maven 2.x (mostly use of SNAPSHOTS and
remote repos), as well as the interdependency between the server and
OpenEJB, I believe that the only way to achieve this level of
trustable build automation, is to build these components from
source. To help make that work, we need to use a very consistent
policy for SVN branch layout. Moving branches to tags and then back
to branches is very harmful in this respect... and I would really
like to see that practice abolished.
--jason
