uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Kottmann <kottm...@gmail.com>
Subject Re: Feedback requested on build approach and tooling
Date Wed, 11 Aug 2010 07:48:34 GMT
  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
>
>
>
>
>
>


Mime
View raw message