The current build tooling, now released and on maven central, seems
to be working.
It improves many things:
* We now can use the maven-release-plugin, which enables our use of
the NEXUS
repository; this process is used by ~ 50 Apache projects, and we now
can follow
the Apache conventional way of doing releases that produce Maven
artifacts, see
http://www.apache.org/dev/publishing-maven-artifacts.html
* RAT (audit reports we need and used to run manually) are now
automated, and
will fail the build if something's wrong here.
* Several deficiencies of our release process, such as some Jars not
including
required License/Notice files, are now avoided, because we use a
standard Apache
process for insuring these are included.
* We now use the standard Apache-wide parent-pom to insure we have
releases
consistent with other Apache projects.
* We no longer have any inter-project dependencies on the SVN
checkout working
directories, except for "aggregate" projects which build sets of
projects, and
our xxx-distr projects, which distribute these. We used to require
checking out
the uimaj node to get tooling needed for building (docbooks, etc.),
and then
check out the sandbox into a particular "parallel" working directory
- this is
no longer required.
* The source releases didn't match SVN. The standard Apache-wide
parent-pom
builds these now, and they match.
* We separated our parent poms into ones providing inheritance-based
factoring,
and ones providing aggregation.
* We changed the way we use maven properties. We previously were
setting
various properties related to releases in a way which generated
warnings from
Maven 3 (and m2eclipse, which embedds maven 3). We now set versions
in a way
that is much more consistent with the Maven "way".
* Many more things were automated. These included deriving the OSGi
versions of
"versions" which don't have a -SNAPSHOT but instead have a ".SNAPSHOT".
-----------------------
Several people have been very helpful in getting improvements to the
build
documentation done.
The main barrier to using our build system at the moment seems to be the
one-time setup required, which has the following unusual things:
1) you have to run Maven 3 beta-1. Maven 2.2.1 (the last stable
version of
maven that will do "releases" correctly with the new NEXUS release
process) has
bugs in property resolutions, that affect our build, and that were
fixed in
3-beta-1.
2) Maven 3 beta 1 fixed some errors that exposed a flaw in the docbkx
plugin -
there's a one line fix to do there, plus you have to rebuild it (mvn
install) to
get a working copy in your local maven repo. The docbook builds
might work
without this, but they will be slow, because the part that's broken
is causing
the xml validation to go out to the internet to find DTDs (instead of
finding
them in the local file system).
Docbkx was chosen because it allowed us to stop using our own
home-grown docbook
publishing tool chain, which in turn caused lots of SVN checkout
issues (we used
to have to checkout multiple projects from multiple SVN places, into a
particular directory structure, in order to build).
3) Use of m2eclipse is optional. If you do use m2eclipse, you have
to use a
particular version, and update that version. This is to work around
a bug in
m2eclipse which wasn't properly recognizing "generated-sources" which
several of
our projects use, now. m2eclipse in the version that fixes this,
won't work
properly with Eclipse 3.6 (Helios) - at least as of the last time I
checked, so
the one-time-setup advises using Eclipse 3.5.2.
The choice to use m2eclipse seems (nevertheless) good, because it is
currently
getting the most "investment", including a new "book" on it, as
compared to the
maven-eclipse-plugin (which we used to use), and it has a lot more
functionality
in Eclipse.
The new build system is documented on our web site here:
http://uima.apache.org/building-uima.html
It has instructions for building without Eclipse, just using command
line
things, and also instructions for using Eclipse via m2eclipse.
For those interested, there's more background information here:
http://uima.apache.org/maven-design.html, and a somewhat older
document on our
wiki describing the motivations for improving the build system, here:
https://cwiki.apache.org/UIMA/redesign-for-more-standards-including-maven.html
The one-time-setups may simplify over time, as parts of the tooling
we depend on
are upgraded with new releases.
Please post feedback on this build process - is this a good
direction, and
whether or not you are able to do builds!
-Marshall
