Thanks, Thilo, for your responses. I have just a couple of small thing to put inline below...
I encourage others to post their experience(s). -Marshall On 8/9/2010 2:58 PM, Thilo Götz wrote: > 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. I agree in general, but not in this specific case. Maven 3 beta-1 has not failed for me, and fixes solid failures that happen with maven 2.2.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). > 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. That whole process was due to our private docbook build tool chain, and is now gone. > 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 >> >> >> >> >> >> >
