It's been an interesting week. First off, I had to leave my brand new apartment in Portland, OR after one night to come down to San Francisco for a three-day intensive Tapestry training session. Teaching Tapestry to twenty people in three days is a bit of a challenge, but the results were very well received; I understand that all new web development at shopping.com will be done using Tapestry.
Meanwhile, in the struggle to get Tapestry 4.0 out, the first vote for a final 4.0 release failed, with a veto by Kent Tong. At issue was the gaps in the documentation, particularily the documentation related to validation. This prompted new contributer Jesse Kuhnert to fill in the gaps there, so I'm in the process of producing a new release candidate, 4.0-rc-2, which will be up on the mirrors sometime tomorrow.
This does show that the process works ... but also underscores that the way many other projects function might not be a bad idea. Apache will generally release numbered releases at intervals, and after the fact elevate a release to "final, stable" status. Had we been following that scheme, we'd be at, say, 4.0.15 around now. If we vote that as a stable release ... well, we don't have to do any extra work beyond publicising it; it will already have been available, presumably, for a week or two minimum before such a vote.
On another front, I've been using Maven 2.0, as I try to rework HiveMind to build under Maven instead of Ant. For the most part, Maven 2 feels more like a finished work than Maven 1 ever did. I haven't been wringing my hands in frustration the same way. I just now downloaded the 2.0.1 release and will see if that fixes the few issues I have been encountering ... such as reports not been run and integrated into the site output.
This does tie together ... once HiveMind and then Tapestry are building under Maven, even having regular point releases will be much less important, since it will be quite easy for the average developer to pull down the source and build. Alas, Tapestry and HiveMind currently raise the bar for that a little too high for the casual developer.
Has anyone gone through the process of converting Forrest XML documentation to Maven XML documentation? They are similar is concept but slightly different in details; I'd like to save myself the effort of writing conversion scripts and stylesheets.
2 comments:
Hi howard,
I've been strugling with maven 2.0 reports as well and my problem was: if there are unit test failures, generation of reports stop. It's a documented bug of the surefire-plugin and the workaround is this:
"mvn site -Dmaven.test.failure.ignore=true"
As I remember, the tests ran but the results were not integrated in; I believe the problem was that the documentation for how to integrate the test was wrong; I added a bug that has been fixed.
Post a Comment