uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Feedback requested on build approach and tooling
Date Thu, 12 Aug 2010 19:41:18 GMT
 Hi Jörn,

Did this error go away when you did the one-time-setup for docbkx?

-Marshall

On 8/11/2010 4:36 AM, Jörn Kottmann wrote:
>  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