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 :-) http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html 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. --Thilo > > -Marshall > > > > > >
