commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim O'Brien" <tobr...@discursive.com>
Subject Re: [jxpath/all] Maven site help
Date Fri, 03 Aug 2007 19:36:36 GMT
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?  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.

> -Matt
>
> >
> > Anyway, I'm here if you need help with either
> > version.
> >
> > <snip/>
> >
> > --
> > Dennis Lundberg
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail:
> > dev-help@commons.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos
& more.
> http://mobile.yahoo.com/go?refer=1GNXIC
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
------
Tim O'Brien: (847) 863-7045

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message