uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo Götz <twgo...@gmx.de>
Subject Re: Feedback requested on build approach and tooling
Date Mon, 09 Aug 2010 18:58:57 GMT
Since I've been griping to Marshall about the build for the last few
months (mostly off-list), I'll respond below.  Let me start by saying
that I now regret very much that we decided a few years ago to switch
our build to maven.  I agreed with that decision at the time.  However,
after many days and weeks lost to maven magic, I now think that was the
wrong thing to do.  A few weeks ago I strongly considered building an
alternative, Ant based build system for those parts of UIMA that I'm
interested in.  I didn't, mostly because I had other things to do. I
still think it's a good idea.

If anybody's interested in what I don't like about maven, there's a blog
that says it a lot better than I ever could.  I agree with almost everything
he says about maven, although maybe I wouldn't have put it quite so
strongly :-)


More inline comments below.

On 8/9/2010 18:03, 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.

That's the one improvement I really care about.

> * 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.

I'll submit that basing the build on beta software is not a good idea.  Maven 2
was bad enough, thank you very much.  The build is our most basic
infrastructure, second only to svn.  When it's broken, everything's broken.
It's broken far too often anyway.  We're doing ourselves no favors by building
with a beta version of maven.

> 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).

I'd rather have a slow docbook build than this error prone procedure that will
likely no longer work in a couple of weeks.  I don't build the docbooks unless
I absolutely have to, because of the Saxon and other downloads that always
required me to start the build 3 times, because it wouldn't continue after
the downloads. So a little more slowdown in the docbook build is perfectly
acceptable to me.

> 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.

Use of m2eclipse is optional only if you don't want to use Eclipse.  That's
not really a choice.  I haven't programmed Java in Emacs for about 10 years.
BTW, last time m2eclipse crapped out on me, I tried using mvn eclipse:eclipse
instead.  No luck.

I do happen to use Helios, and I have yet to find a plugin that doesn't work
with it.  Way to go, Maven.

> 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.

I followed those instruction 3 or 4 times, and once they seemed to work
for about 5 minutes.  I have given up.  As I told Marshall privately,
I'll wait for a few non-Maven experts like me to confirm that they can
build, make and commit changes over a couple of days (on Linux, if possible)
before I'll try again.

Marshall, I realize that you put in an enormous amount of work here,
and that some things are probably better than they were.  However, the
basic build *must* work without complications.  The rest is important,
too, but it's a secondary concern.

If somebody opens an issue and I want to look at the source code
and try some changes, I don't want to have to send queries back
to the list and ask for help before I can even look at the source
code in eclipse.  The Maven Eclipse plugin was annoying, but it
was a know evil and worked most of the time.  And when it didn't
you could hand-massage the classpath or whatever.  Still better
than no Eclipse at all.

> 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!

Please do.  If I'm the only one with problems, I'll shut up and try to figure
out why that is.


> -Marshall

View raw message