You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Benson <gu...@yahoo.com> on 2007/08/03 19:20:36 UTC
[jxpath/all] Maven site help
Though I am an avid reader of fantasy fiction, I
don't think magic has much place in the realm of
software development. For this reason I despair--and
I say this in awareness that I may offend some
folks--whenever I am forced to work with Maven. I can
never figure out what's going on, and any
documentation I find doesn't tell me what I need to
know, at least (to be fair) not in such a way that I
recognize the datum that will help me when I see it.
From this perspective, will someone please recommend
a resource that will tell me in no uncertain terms WTF
is going on with a Maven site and/or particularly your
"average" Apache Commons site? I want to bring the
JXPath site more in line with e.g. IO/Lang for the 1.3
release but am at a loss to determine how to invoke
some of the black magic necessary to accomplish this.
Thanks,
Matt
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
--- Tim O'Brien <to...@discursive.com> wrote:
> On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
> >
> > --- Dennis Lundberg <de...@apache.org> wrote:
> >
> > > Matt Benson wrote:
> > > > Thanks for your response, Dennis:
> > > >
> > > > --- Dennis Lundberg <de...@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
Re: [jxpath/all] Maven site help
Posted by simon <sk...@apache.org>.
On Fri, 2007-08-03 at 13:48 -0700, Matt Benson wrote:
> --- Dennis Lundberg <de...@apache.org> wrote:
>
> 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.
Maven2 really is a whole lot better than maven1. It's *much* faster and
*much* stabler. It's also the currently supported version.
Yes maven can be rather mysterious at times; I suffer the same pain as
you :-). However I can't imagine getting the sort of nice websites we
currently have from any other tool without major effort and complexity -
at which point we'd all have to learn this new, unique and badly
documented system rather than maven. I don't think there's an easy
solution to this problem. Probably best to just improve our
documentation about how to get Maven to work for us..
There is a nice maven manual available for download called "Better
Builds with Maven". See the documentation link on the maven.apache.org
site.
I don't see why maven1 support is necessary. We do need to deploy to the
maven1 repository, so maven1 users can use the release. But there may be
easier ways of doing that than writing a complete maven1 buildfile. Most
components currently have maven1 builds because they were first
converted over before maven2 existed..
BTW, I see that Mergere.com (home of many maven developers) is now
DevZuz.com. That had me confused for a while..
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
--- Dennis Lundberg <de...@apache.org> wrote:
> Matt Benson wrote:
> > --- Dennis Lundberg <de...@apache.org> wrote:
> >
> >> Tim O'Brien wrote:
> >>> On 8/3/07, Matt Benson <gu...@yahoo.com>
> >> wrote:
> >>>> --- Dennis Lundberg <de...@apache.org> wrote:
> >>>>
> >>>>> Matt Benson wrote:
> >>>>>> Thanks for your response, Dennis:
> >>>>>>
> >>>>>> --- Dennis Lundberg <de...@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.
>
> No, you'll need to understand at least one of them.
>
> I'm putting together Maven 2 files for JXPath as we
> speak. Either I'll
> just commit them to svn and you can use them if you
> want to, or I'll
> send them to you directly so you can have a look at
> them.
>
Feel free to commit directly; if you can't get it
right there's little hope for me! ;) ...and TIA
-Matt
> --
> Dennis Lundberg
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> dev-help@commons.apache.org
>
>
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Dennis Lundberg <de...@apache.org>.
Matt Benson wrote:
> --- Dennis Lundberg <de...@apache.org> wrote:
>
>> Tim O'Brien wrote:
>>> On 8/3/07, Matt Benson <gu...@yahoo.com>
>> wrote:
>>>> --- Dennis Lundberg <de...@apache.org> wrote:
>>>>
>>>>> Matt Benson wrote:
>>>>>> Thanks for your response, Dennis:
>>>>>>
>>>>>> --- Dennis Lundberg <de...@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.
No, you'll need to understand at least one of them.
I'm putting together Maven 2 files for JXPath as we speak. Either I'll
just commit them to svn and you can use them if you want to, or I'll
send them to you directly so you can have a look at them.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
--- Dennis Lundberg <de...@apache.org> wrote:
> Tim O'Brien wrote:
> > On 8/3/07, Matt Benson <gu...@yahoo.com>
> wrote:
> >> --- Dennis Lundberg <de...@apache.org> wrote:
> >>
> >>> Matt Benson wrote:
> >>>> Thanks for your response, Dennis:
> >>>>
> >>>> --- Dennis Lundberg <de...@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
Re: [jxpath/all] Maven site help
Posted by Dennis Lundberg <de...@apache.org>.
Tim O'Brien wrote:
> On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
>> --- Dennis Lundberg <de...@apache.org> wrote:
>>
>>> Matt Benson wrote:
>>>> Thanks for your response, Dennis:
>>>>
>>>> --- Dennis Lundberg <de...@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
Re: [jxpath/all] Maven site help
Posted by Tim O'Brien <to...@discursive.com>.
On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Dennis Lundberg <de...@apache.org> wrote:
>
> > Matt Benson wrote:
> > > Thanks for your response, Dennis:
> > >
> > > --- Dennis Lundberg <de...@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
Re: [jxpath/all] Maven site help
Posted by simon <si...@chello.at>.
On Fri, 2007-08-03 at 12:23 -0700, Matt Benson wrote:
> 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?
Maven2 really is a whole lot better than maven1. It's *much* faster and
*much* stabler. It's also the currently supported version.
Yes maven can be rather mysterious at times; I'm not convinced it is the
best of all build systems. However I can't imagine getting the sort of
nice websites we currently have from any other tool without major effort
and complexity - at which point we'd all have to learn this new, unique
and badly documented system rather than maven. I don't think there's an
easy solution to this problem. Probably best to just improve our
documentation about how to get Maven to work for us..
There is a nice maven manual available for download called "Better
Builds with Maven". See the documentation link on the maven.apache.org
site.
BTW, I see that Mergere.com (home of many maven developers) is now
DevZuz.com. That had me confused for a while..
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
--- Dennis Lundberg <de...@apache.org> wrote:
> Matt Benson wrote:
> > Thanks for your response, Dennis:
> >
> > --- Dennis Lundberg <de...@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?
-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
Re: [jxpath/all] Maven site help
Posted by Dennis Lundberg <de...@apache.org>.
Matt Benson wrote:
> Thanks for your response, Dennis:
>
> --- Dennis Lundberg <de...@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 :-)
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
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
Thanks for your response, Dennis:
--- Dennis Lundberg <de...@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...
>
> Let me know if you have any more specific questions
> and I'll try to help.
Thanks again,
Matt
>
> Matt Benson wrote:
> > Though I am an avid reader of fantasy fiction, I
> > don't think magic has much place in the realm of
> > software development. For this reason I
> despair--and
> > I say this in awareness that I may offend some
> > folks--whenever I am forced to work with Maven. I
> can
> > never figure out what's going on, and any
> > documentation I find doesn't tell me what I need
> to
> > know, at least (to be fair) not in such a way that
> I
> > recognize the datum that will help me when I see
> it.
> >
> > From this perspective, will someone please
> recommend
> > a resource that will tell me in no uncertain terms
> WTF
> > is going on with a Maven site and/or particularly
> your
> > "average" Apache Commons site? I want to bring
> the
> > JXPath site more in line with e.g. IO/Lang for the
> 1.3
> > release but am at a loss to determine how to
> invoke
> > some of the black magic necessary to accomplish
> this.
> >
> > Thanks,
> > Matt
> >
> >
> >
>
____________________________________________________________________________________
> > Shape Yahoo! in your own image. Join our Network
> Research Panel today!
>
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
>
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail:
> dev-help@commons.apache.org
> >
>
>
> --
> Dennis Lundberg
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> dev-help@commons.apache.org
>
>
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Dennis Lundberg <de...@apache.org>.
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.
Let me know if you have any more specific questions and I'll try to help.
Matt Benson wrote:
> Though I am an avid reader of fantasy fiction, I
> don't think magic has much place in the realm of
> software development. For this reason I despair--and
> I say this in awareness that I may offend some
> folks--whenever I am forced to work with Maven. I can
> never figure out what's going on, and any
> documentation I find doesn't tell me what I need to
> know, at least (to be fair) not in such a way that I
> recognize the datum that will help me when I see it.
>
> From this perspective, will someone please recommend
> a resource that will tell me in no uncertain terms WTF
> is going on with a Maven site and/or particularly your
> "average" Apache Commons site? I want to bring the
> JXPath site more in line with e.g. IO/Lang for the 1.3
> release but am at a loss to determine how to invoke
> some of the black magic necessary to accomplish this.
>
> Thanks,
> Matt
>
>
> ____________________________________________________________________________________
> Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Niall Pemberton <ni...@gmail.com>.
On 8/3/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
> > Though I am an avid reader of fantasy fiction, I
> > don't think magic has much place in the realm of
> > software development. For this reason I despair--and
> > I say this in awareness that I may offend some
> > folks--whenever I am forced to work with Maven. I can
> > never figure out what's going on, and any
> > documentation I find doesn't tell me what I need to
> > know, at least (to be fair) not in such a way that I
> > recognize the datum that will help me when I see it.
> >
> > From this perspective, will someone please recommend
> > a resource that will tell me in no uncertain terms WTF
> > is going on with a Maven site and/or particularly your
> > "average" Apache Commons site? I want to bring the
> > JXPath site more in line with e.g. IO/Lang for the 1.3
> > release but am at a loss to determine how to invoke
> > some of the black magic necessary to accomplish this.
>
> Not quite sure what you want - JXPath site doesn't look that out of
> line with what lang/io look like. You only have a maven1 build ATM -
> if you're happy to stick with that then the file that controls the
> menu is xdocs/navigation.xml - all the other xml files in the xdocs
> directory get converted to html pages - so if you create a
> xdocs/foo.xml - it will generate a foo.html page and you can add menu
> reference to foo.html in your navigation.xml to put a link on the
> menu.
>
> If you want to use maven2 - then you need some other bits (which I'm
> happy to help with if you want).
>
> Perhaps you could be more specific about what your're trying to achieve though.
One other point if you want the maven standard "Project Documentation"
sub-menu generated then you need to change (or comment out)
maven.xdoc.includeProjectDocumentation to "yes" in your
project.properties (and probably remove the "maven reports" link from
navigation.xml)
Niall
> Niall
>
>
> > Thanks,
> > Matt
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Matt Benson <gu...@yahoo.com>.
--- Niall Pemberton <ni...@gmail.com> wrote:
> On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
> > Though I am an avid reader of fantasy fiction, I
> > don't think magic has much place in the realm of
> > software development. For this reason I
> despair--and
> > I say this in awareness that I may offend some
> > folks--whenever I am forced to work with Maven. I
> can
> > never figure out what's going on, and any
> > documentation I find doesn't tell me what I need
> to
> > know, at least (to be fair) not in such a way that
> I
> > recognize the datum that will help me when I see
> it.
> >
> > From this perspective, will someone please
> recommend
> > a resource that will tell me in no uncertain terms
> WTF
> > is going on with a Maven site and/or particularly
> your
> > "average" Apache Commons site? I want to bring
> the
> > JXPath site more in line with e.g. IO/Lang for the
> 1.3
> > release but am at a loss to determine how to
> invoke
> > some of the black magic necessary to accomplish
> this.
>
> Not quite sure what you want - JXPath site doesn't
> look that out of
> line with what lang/io look like. You only have a
> maven1 build ATM -
> if you're happy to stick with that then the file
> that controls the
> menu is xdocs/navigation.xml - all the other xml
> files in the xdocs
> directory get converted to html pages - so if you
> create a
> xdocs/foo.xml - it will generate a foo.html page and
> you can add menu
> reference to foo.html in your navigation.xml to put
> a link on the
> menu.
>
> If you want to use maven2 - then you need some other
> bits (which I'm
> happy to help with if you want).
>
> Perhaps you could be more specific about what
> your're trying to achieve though.
>
I hadn't wanted to get too specific because I thought
it would be more valuable for me to find the
resource(s) that would enlighten me in a general way.
In this particular case I have just now been able to
find the answer to a problem by comparing
project.properties files; this led to my discovery of
the maven.xdoc.includeProjectDocumentation property.
After having found this I was able to Google for it
and find the part of the Maven 1.x xdoc plugin
documentation that describes it. I had already been
to the plugin's docs and failed to recognize its
properties link as belonging to the plugin itself. So
maybe part of my problem is unfamiliarity with the
manual. I guess I will present future issues on a
case-by-case basis.
Thanks,
Matt
> Niall
>
>
> > Thanks,
> > Matt
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> dev-help@commons.apache.org
>
>
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jxpath/all] Maven site help
Posted by Niall Pemberton <ni...@gmail.com>.
On 8/3/07, Matt Benson <gu...@yahoo.com> wrote:
> Though I am an avid reader of fantasy fiction, I
> don't think magic has much place in the realm of
> software development. For this reason I despair--and
> I say this in awareness that I may offend some
> folks--whenever I am forced to work with Maven. I can
> never figure out what's going on, and any
> documentation I find doesn't tell me what I need to
> know, at least (to be fair) not in such a way that I
> recognize the datum that will help me when I see it.
>
> From this perspective, will someone please recommend
> a resource that will tell me in no uncertain terms WTF
> is going on with a Maven site and/or particularly your
> "average" Apache Commons site? I want to bring the
> JXPath site more in line with e.g. IO/Lang for the 1.3
> release but am at a loss to determine how to invoke
> some of the black magic necessary to accomplish this.
Not quite sure what you want - JXPath site doesn't look that out of
line with what lang/io look like. You only have a maven1 build ATM -
if you're happy to stick with that then the file that controls the
menu is xdocs/navigation.xml - all the other xml files in the xdocs
directory get converted to html pages - so if you create a
xdocs/foo.xml - it will generate a foo.html page and you can add menu
reference to foo.html in your navigation.xml to put a link on the
menu.
If you want to use maven2 - then you need some other bits (which I'm
happy to help with if you want).
Perhaps you could be more specific about what your're trying to achieve though.
Niall
> Thanks,
> Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org