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? 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: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > ____________________________________________________________________________________ > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ------ Tim O'Brien: (847) 863-7045 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
