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 08:36:07 GMT
  Looks like this error is related to this one time setup:
http://uima.apache.org/one-time-setup.html#docbkx-setup

Jörn

On 8/11/10 9:48 AM, Jörn Kottmann wrote:
>  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