Tim O'Brien wrote:
On 8/3/07, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Matt Benson wrote:
Thanks for your response, Dennis:
--- Dennis Lundberg <[EMAIL PROTECTED]> wrote:
The site for jxpath builds fine for me using
Maven
1.0.2. It looks as
good as any of the other components sites that
are
build with M1.
Which reports that are generated is configured in
the <reports> section
of the file project.xml. Most of the plugins in
Maven 1 can be tweaked
by adding or changing properties in the file
project.properties.
If you need more info about a certain plugin,
check
the site for that
plugin. Start at
http://maven.apache.org/maven-1.x/plugins/bundledHistory.html
and choose the plugin you're interested in. Each
plugin has an item
"Plugin properties" in the menu that gives more
information.
If you want to, we could convert the site to use
Maven 2 instead.
<cringe> is there any reason I'd want to do that?
:o
Seriously, 'cause I don't know...
The reason would be that commons is moving in that
direction. It might
be a waste of time for you to learn Maven 1 now, and
then have to learn
Maven 2 in a short while. You could just as well
jump right on to Maven
2. But that's your call :-)
Is the fact that the sites can be made uniform the
driving reason to use Maven 1 or 2?
Yep, that and as Tim pointed out standardization. But it isn't just for
producing sites. It's a replacement for Ant, at least in the long run.
If,
hypothetically speaking, there were a third option
that could generate the site identically, would there
be a good reason to forbid its use?
Yes, standardization. Go ahead and create your own site generation
technology, but commit to sticking around to update it forever.
Commons project (especially) experience bursts of interest and
activity. A project might have a dedicated release manager
throughout the years (example would be Rahul and SCXML), but another
project might have a release manager that disappears for a year, or a
series of release managers spanning multiple years (example would be
something like Codec). The only way certain subproject's sites are
not going to fall into disrepair is if there is a common way to
generate them.
If a project has some custom site build process, it just makes it that
much harder for someone to jump in and fix a bug and keep the
documentation up to date.
Instead of just turning you nose up on a Maven site, someone needs to
create a commons-skin similar to what the Spring Framework guys are
doing, and similar to what the Wicket people are doing.
We already have a commons-skin. That is one of the reasons I'm pushing
for Maven 2 here. The skin takes care of all the look-and-feel stuff for
you. You don't have to worry about it. Just concentrate on creating and
organizing content.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
