uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject reducing the number of "releases" of build tooling
Date Mon, 18 Oct 2010 14:22:29 GMT
 Each "release" of the build tooling takes time and effort, from several people,
for doing the release, preparing test versions of our code referring to the new
release, and testing the build tooling, and then doing an svn "merge" of the
updated parent-pom references to pick up the new versions, back into the trunk.

I would like to reduce this :-).  Here's a proposal:

1) Cancel the pending [VOTE] on the current build tooling, and revert the trunk
back to the previous SNAPSHOT.

2) Update the current projects in UIMA that use these build tools, to depend on
that previous SNAPSHOT, instead of depending on "released" versions. 

3) Step 2) will create a "problem" when releasing the projects that use these: 
projects, when released, cannot depend on snapshots.  To overcome this, at the
time we release, say uimaj-sdk project, do one of the following:

3a) Change the build tooling for parent-pom-dist to include a <modules><module>
that specifies the uimaj-distr project, and then do the release from the
parent-pom-top.  This will release the build tooling, plus all the items in
uimaj-distr, together. 

Downside of this: it introduces a cross SVN-checkout directory dependency,
because the <module> must have some kind of relative reference from a "build"
checkout (working directory A, say), and the uimaj SDK checkout (working
directory B, for instance).  It also requires that, after releasing, we update
parent-pom-distr to remove the <modules> section.

3b) When it's time to release, release the build tooling, like we do now, and
before closing the Nexus staging repo, also release the uimaj-distr projects. 
Release will complain that there are "still" snapshot poms, but according to
http://jira.codehaus.org/browse/MRELEASE-583 (which is included in the set of
things included in the 2.1 version, which we're now using) the release plugin
will let you change these to release levels, as part of the release:prepare process.

With this approach, we can fiddle the build tooling as much as we need to while
getting a release to "go", and then release things.

So, I'm thinking 3b) is the way to go.  Other opinions?


View raw message