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.
Use of Maven was previously discussed in http://
marc.theaimsgroup.com/?t=112917760100003&r=1&w=2 and Yoav had a few
comments worth repeating:
On 2005-10-13:
-0.5 on using Maven. My experience with it has been that it's kind
of nice for
generating project documentation, but for most real-life (i.e. complex
dependencies, multiple builders on different environments) projects,
the setup
overhead is not worth the benefits.
On 2005-11-18:
If you want to come up with a Maven build file, have a blast. But
the key
thing is maintaining it afterwards: it won't replace the Ant file,
but you'd
still have to maintain it current as we change dependencies and stuff...
I'm definitely uncertain if we can effectively use Maven for the
total product build, but it seems to offer a lot of benefits for
project documentation. I think it is worth some experimentation to
see how far we can take it. If we don't migrate to Maven for
documentation, then we should at least try to migrate to Velocity 1.4
(or less likely Forrest).
Unfortunately, there is not a great solution regarding the
dependencies from Sun. The Maven guide on the topic (http://
maven.apache.org/guides/mini/guide-coping-with-sun-jars.html)
mentions that "When you add a Sun dependency ... then Maven 2.x can
help you locate the JARs by providing the site where they can be
retrieved." However, I haven't seen that actually work in practice.
The download site information is in the resources, however a simple
Maven invocation doesn't provide the link to the Sun site and
instructions on installing the Sun jars. Something I need to ask on
the Maven list, since maybe you only get that with a particular build
switch.
At some point, if things go well, we would need to consider
rearranging our source tree to align with the Maven Standard
Directory Layout (http://maven.apache.org/guides/introduction/
introduction-to-the-standard-directory-layout.html).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
