Tim O'Brien wrote:
> On 8/3/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
>> --- Dennis Lundberg <dennisl@apache.org> wrote:
>>
>>> Matt Benson wrote:
>>>> Thanks for your response, Dennis:
>>>>
>>>> --- Dennis Lundberg <dennisl@apache.org> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|