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:12:07 GMT

--- Tim O'Brien <tobrien@discursive.com> 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?  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.
> 

Actually I was thinking along the lines of a tool that
would generate identical output from identical
(existing) input.  That doesn't seem like too much of
a breaker.  I really do see your point wrt
attrition-tolerance, at least in the context of the
Commons project, but that doesn't change the fact that
Maven makes me feel like a helpless spectator in my
build process.  :|  I can't help but have the
impression that customizing a Maven build entails the
same amount of work as orchestrating a build from
scratch with pick-another-build-technology.  Obviously
I'm biased by my own experience as well and I don't
intend to deny it.

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

In fairness, I'm turning up my nose at
Maven-as-a-methodology, not the sites it generates. 
But I'm sure this discussion's been had before, and
it's obvious what the result was.  I'm in Rome now, so
I don't see any point in this becoming any kind of
flame war.

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

How does (or otherwise) this relate to what is
"commons-skin" in svn?

-Matt

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



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get
online.
http://smallbusiness.yahoo.com/webhosting 

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


Mime
View raw message