update trunk poms to depend on -SNAPSHOT versions of build tooling
------------------------------------------------------------------
Key: UIMA-1905
URL: https://issues.apache.org/jira/browse/UIMA-1905
Project: UIMA
Issue Type: Task
Components: Build, Packaging and Test
Reporter: Marshall Schor
Assignee: Marshall Schor
Implement "3b)" below:
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:
Update the current projects in UIMA that use these build tools, to depend on
that previous SNAPSHOT, instead of depending on "released" versions.
This 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
