Matt Benson wrote:
--- Dennis Lundberg <[EMAIL PROTECTED]> wrote:
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.
I sense I'll not be able to escape M(1|2). Groan, I
was hoping to avoid M2 for some time yet... Let me do
some research to see exactly what I'm getting into if
I opt to switch JXPath. Aren't we now in the mode of
support M1-even-after-adding-M2-support though? That
would make it seem as though I still have to mess with
M1 even if I opt to "upgrade" to M2.
No, you'll need to understand at least one of them.
I'm putting together Maven 2 files for JXPath as we speak. Either I'll
just commit them to svn and you can use them if you want to, or I'll
send them to you directly so you can have a look at them.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
