commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [jxpath/all] Maven site help
Date Fri, 03 Aug 2007 19:52:30 GMT
Tim O'Brien wrote:
> On 8/3/07, Matt Benson <> wrote:
>> --- Dennis Lundberg <> wrote:
>>> Matt Benson wrote:
>>>> Thanks for your response, Dennis:
>>>> --- Dennis Lundberg <> 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
>>>>> If you need more info about a certain plugin,
>>> check
>>>>> the site for that
>>>>> plugin. Start at
>>>>> 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:
For additional commands, e-mail:

View raw message