"Unmaintainable" may be a bit much, but I think it is fair to say that
moving to something more modern, like Maven2, could yield some benefits. As
Curt mentioned, there are some really nice features around documentation.
We need to figure out the options and settings, but I think it has greater
potential than trying to do the same things with our existing setup for site
generation. And I still like the automatic dependency determination and
download. If it weren't for the stupid Sun license for the jar files,
everything could be downloaded and generated with almost no configuration.
I think that Maven2 has really raised the bar. When Joakim was showing us
how to setup Maven2 and create the pom.xml file, I downloaded a tiny little
executable from the maven site, added one new env and path setting, created
a really simple pom.xml and we were off. The small Maven2 download
bootstrapped itself and started downloading the needed resources for the
log4j build. Of course, it helped to have an expert at hand, but I think
this could really help users generate the code on their desktop easier as
well. The Ant installation was never quite as easy, IMHO.
-Mark
----- Original Message -----
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, December 19, 2005 8:02 AM
Subject: Re: Exploration of use of Maven for site generation and build
At 12:07 AM 12/17/2005, Curt Arnold wrote:
Mark Womack, Ron Grabowski (from log4net) and I just recently
returned from ApacheCON US 2005. I expect that Mark will be
preparing a report on the Birds of a Feather on Monday night, our
discussions on a release plan for 1.3 and thoughts on 2.0.
One of my concerns had been the content and production of the project
documentation. The current documentation for log4j is generated
using the contents of the former logging-site CVS module (now http://
svn.apache.org/repos/asf/logging/site/trunk). The logging-site
module is not available for download, so someone who has downloaded a
log4j distribution and wants to regenerate the documentation has to
use Subversion to get the contents of logging-site. In addition,
logging-site has not been consistently tagged when log4j releases
have been made.
I had been interested in seeing if Apache Forrest (http://
forrest.apache.org) might be an better solution, however comments I
overheard at the Hackathon and the Forrest session, suggested that it
might be a bit of an overkill for our needs. In a discussion at the
BoF, one of the attendees (Mark has the contact info) mentioned that
Maven might be a better fit and helped Mark assemble an initial Maven
project description. In particular, Maven has extensive support for
generating code analysis and coverage reports which could be useful
for log4j development. For example, see http://db.apache.org/torque/
runtime/maven-reports.html for 18 different code analysis reports
performed on the Torque code.
Mark committed the initial pom.xml without referencing a bug report.
I continued work on it when I returned and logged a bug (http://
issues.apache.org/bugzilla/show_bug.cgi?id=37930) and committed my
changes. In the bug report, I described the current documentation
generation system as unmaintainable. The tools provided by logging- site
appear to be a development snapshot of Velocity 1.4. The jars
provided seem to be fairly dated and include Ant 1.4.1 (current is
1.6.5), log4j 1.1.3 (current is 1.2.14), commons-collections-2.0
(current is 3.1), velocity-1.4-dev.jar (current is 1.4), jdom-b8
(latest is 1.0), and xerces-1.4.4 (latest is 2.7.1). It may be just
the dependencies of the Velocity development build at the time of the
snapshot. Since Velocity 1.4 has apparently been released since the
snapshot has been made, it may be possible to eliminate the
dependency of log4j on logging-site and replace it with a dependency
on velocity 1.4, but I have not attempted that. However, if site
generation depends on stuff that was either eliminated or
significantly changed between the development snapshot and the final
release, then the initial characterization as "unmaintainable" might
be accurate.
The log4j site is build on top of Anakia which is itself based on Velocity.
By the way, the velocity site itself is built on top of Anakia. How
difficult would it be to upgrade to velocity-1.4 from velocity-1.4-dev? My
guess would be that it would not be difficult at all. In the unlikely case
of problems while upgrading, is there any reason the velocity-user list
could not be contacted? The characterization of the current system as
"unmaintainable" may be somewhat premature.
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
