On Jan 8, 2007, at 10:20 AM, Jason Dillon wrote:
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 didn't make the change to Geronimo/OpenEJB that broke the
compatibility. I do/did realize that a publish needed to occur. I
would have done it, if I knew how. I've never done it. I'm happy to
learn...
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.
Agreed.
* * *
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.
I think it's Dain that proposed the current policy of specs. So, I'll
let him (or others) follow up on this...
--kevan
