commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [jxpath/all] Maven site help
Date Fri, 03 Aug 2007 20:48:42 GMT

--- Dennis Lundberg <dennisl@apache.org> wrote:

> 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.
> 

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.

-Matt

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



      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto
Green Center.
http://autos.yahoo.com/green_center/ 

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


Mime
View raw message