I did set up everything a while back, and now updated my workspace and
tried
to build it but it fails with this error:
[ERROR] Failed to execute goal
com.agilejava.docbkx:docbkx-maven-plugin:2.0.10:generate-pdf (pdf) on
project uima-docbook-tutorials-and-users-guides: Failed to transform
tutorials_and_users_guides.xml. Failure reading
/Users/joern/dev/uima/uimaj/uima-docbook-tutorials-and-users-guides/src/docbook/tutorials_and_users_guides.xml:
Server returned HTTP response code: 403 for URL:
http://www.oasis-open.org/docbook/xml/4.4/calstblx.dtd -> [Help 1]
Even tough my machine was connected to the internet. Is this server just
down once in a while ?
Is it possible to build UIMA offline after all the artifacts have been
downloaded ?
Jörn
On 8/9/10 6:03 PM, Marshall Schor wrote:
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
