You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2003/10/01 01:29:25 UTC
The Forrest Option
I know the discussion on whether to use Forrest or Maven to generate the
Struts website was a few weeks back, but unfortunately, at the time, I was
too busy to participate. I'd like to lay out a case for Forrest, not to
insist Struts uses it, but rather to make sure the decision is made with
all the available information.
In short, Forrest offers these benefits over Maven's website generation:
- Multiple output formats including PDF and HTML
- SVG to PNG rendering
- Built for handling and aggregating multiple XML sources like RRS (soon
wiki and Docbook)
- Power and features of Cocoon including charting, web services
integration, scripting support, etc.
Further, deciding between Forrest and Maven isn't an either/or situation.
There exists a Forrest plugin for Maven and it would be easy to integrate
Maven's reports into a Forrest site build.
To me, the key feature of Forrest is the first one listed, multiple
outputs. This is especially useful for documentation as PDF is much
better than HTML for printing for the many users that like hard copies.
Finally, Forrest content is built to be presented in not only multiple
output formats, but multiple skins. To demonstrate this, I've quickly
redone the Struts site into Forrest format (which is very similiar to the
current format thanks to the xhtml work of late). I've only converted the
menu and the main page, which should be sufficient.
Please note, this examples are not polished and only serve to demonstrate
the skinability of Forrest.
Krysalis style: http://www.twdata.org/dakine/site/
Avalon/Tigris style: http://www.twdata.org/dakine/site1/
Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
If we did decide to go with Forrest, I'm willing to convert the old site
over and help handle any integration. I'm most definately not an expert
at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
easy.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>--- Robert Leland <rl...@apache.org> wrote:
>
>
>>Don,
>>
>> I have one request and that is to leave the existing maven files
>> in place since they do currently generate a web site with the reports.
>>
>>
>
>I must be confused with the several projects I'm working on. So, Maven is
>already setup in Struts to run the builds? If so, why are we going to add
>Forrest to the builds? Why not just start building the site and distro
>with Maven?
>
>
The site was about like what Don had the front page, along with
javadoc(current+legacy), clover reports, PMD, changelogs.
In fact it had all the features that the commons validator does, check
it out:
http://jakarta.apache.org/commons/validator/index.html
What was needed was to tie in the userguide, and other more detailed docs,
which should have been straight forward, but I have so little time now.
What wasn't setup in the builds was the sub-projects of contrib, etc...
>David
>
>
>
>>Craig R. McClanahan wrote:
>>
>>
>>
>>>Don Brown wrote:
>>>
>>>
>>>
>>>>I know the discussion on whether to use Forrest or Maven to generate
>>>>
>>>>
>>the
>>
>>
>>>>Struts website was a few weeks back, but unfortunately, at the time,
>>>>I was
>>>>too busy to participate. I'd like to lay out a case for Forrest, not
>>>>
>>>>
>>to
>>
>>
>>>>insist Struts uses it, but rather to make sure the decision is made
>>>>
>>>>
>>with
>>
>>
>>>>all the available information.
>>>>
>>>>In short, Forrest offers these benefits over Maven's website
>>>>
>>>>
>>generation:
>>
>>
>>>>- Multiple output formats including PDF and HTML
>>>>- SVG to PNG rendering
>>>>- Built for handling and aggregating multiple XML sources like RRS
>>>>
>>>>
>>(soon
>>
>>
>>>>wiki and Docbook)
>>>>- Power and features of Cocoon including charting, web services
>>>>integration, scripting support, etc.
>>>>
>>>>Further, deciding between Forrest and Maven isn't an either/or
>>>>situation.
>>>>There exists a Forrest plugin for Maven and it would be easy to
>>>>integrate
>>>>Maven's reports into a Forrest site build.
>>>>
>>>>To me, the key feature of Forrest is the first one listed, multiple
>>>>outputs. This is especially useful for documentation as PDF is much
>>>>better than HTML for printing for the many users that like hard
>>>>
>>>>
>>copies.
>>
>>
>>>>Finally, Forrest content is built to be presented in not only
>>>>
>>>>
>>multiple
>>
>>
>>>>output formats, but multiple skins. To demonstrate this, I've
>>>>
>>>>
>>quickly
>>
>>
>>>>redone the Struts site into Forrest format (which is very similiar to
>>>>
>>>>
>>>>the
>>>>current format thanks to the xhtml work of late). I've only
>>>>converted the
>>>>menu and the main page, which should be sufficient.
>>>>
>>>>Please note, this examples are not polished and only serve to
>>>>demonstrate
>>>>the skinability of Forrest.
>>>>
>>>>Krysalis style: http://www.twdata.org/dakine/site/
>>>>Avalon/Tigris style: http://www.twdata.org/dakine/site1/
>>>>Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
>>>>
>>>>If we did decide to go with Forrest, I'm willing to convert the old
>>>>
>>>>
>>site
>>
>>
>>>>over and help handle any integration. I'm most definately not an
>>>>
>>>>
>>expert
>>
>>
>>>>at Forrest, but am familiar with Cocoon and thankfully, Forrest is
>>>>pretty
>>>>easy.
>>>>
>>>>
>>>>
>>>>
>>>Looking at the potential here, I'm inclined to suggest we accept Don's
>>>
>>>
>>>offer to help set this up -- although perhaps at first in a standalone
>>>
>>>
>>>directory structure that can be undone if we discover that we don't
>>>like it. One advantage is that we can do it without having to migrate
>>>
>>>
>>>the build system to Maven first.
>>>
>>>As for skins, I sure like the Avalon/Tigris or Krysalis examples, and
>>>sure wonder why the Forrest developers chose the native style they
>>>ship with, when they could do something as nice looking as either of
>>>these. But, if I understand what you're saying, skins is essentially
>>>a runtime (when you're generating the HTML) choice; we don't have to
>>>make an irrevocable decision at any point in time.
>>>
>>>
>>>
>>>>Don
>>>>
>>>>
>>>>
>>>>
>>>Craig
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Shopping - with improved product search
>http://shopping.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
Re: The Forrest Option
Posted by Ted Husted <hu...@apache.org>.
Robert Leland wrote:
> The whole Maven idea came because we felt the build
> process of ant struts-legacy was broken or needed some
> serious work. If Don wants to put energy into redoing our site's look
> and feel that then here is my +1. Just know we are still
> left with the original problem.
Struts-Legacy is a very special case. By rights, it should have gone to
the Commons. It should be treated as if it were an external product. So,
just like the Commons JARs, if you were doing everything from scratch,
you would build struts-legacy first, and then the Struts core.
It's possible that the underlying problem is that we didn't release a
struts-lib distribution with Struts 1.1 (as we did with some of the
milestones).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Build improvements (was Re: The Forrest Option)
Posted by Don Brown <mr...@twdata.org>.
On Wed, 1 Oct 2003, Ted Husted wrote:
<snip />
> Ah, well, you see we don't have JARs in our CVS. That's one of the
> reasons people have trouble building Struts at first. They have to go
> off and snag all the JARs themselves. Though, it seems like ruper might
> help in that regard.
Doh! I blocked out the memory of having to get everything setup. I do
that with traumatic events :)
Don
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Build improvements (was Re: The Forrest Option)
Posted by Ted Husted <hu...@apache.org>.
Don Brown wrote:
> Yes, this won't help our build at all. Until we get Maven running, there
> are some options to bring some Maven features over to Ant. For example,
> if we wanted to get rid of jars in our CVS, we could use something like
> http://www.krysalis.org/ruper/ or
> http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168.
> Ant 1.6 has the ability to import build files which could help to spread
> the load.
Ah, well, you see we don't have JARs in our CVS. That's one of the
reasons people have trouble building Struts at first. They have to go
off and snag all the JARs themselves. Though, it seems like ruper might
help in that regard.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Build improvements (was Re: The Forrest Option)
Posted by Chris Gastin <ch...@gastin.com>.
Don:
I don't know much about Forrest, but I am starting to read up on it, where
possible. I am willing to throw some muscle work your way, just let me know
what I can do.
Chris Gastin
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, October 01, 2003 3:12 PM
Subject: Build improvements (was Re: The Forrest Option)
> Yes, this won't help our build at all. Until we get Maven running, there
> are some options to bring some Maven features over to Ant. For example,
> if we wanted to get rid of jars in our CVS, we could use something like
> http://www.krysalis.org/ruper/ or
>
http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168.
> Ant 1.6 has the ability to import build files which could help to spread
> the load.
>
> Don
>
> On Wed, 1 Oct 2003, Robert Leland wrote:
>
> > The whole Maven idea came because we felt the build
> > process of ant struts-legacy was broken or needed some
> > serious work. If Don wants to put energy into redoing our site's look
> > and feel that then here is my +1. Just know we are still
> > left with the original problem.
> >
> > -Rob
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Build improvements (was Re: The Forrest Option)
Posted by Don Brown <mr...@twdata.org>.
Yes, this won't help our build at all. Until we get Maven running, there
are some options to bring some Maven features over to Ant. For example,
if we wanted to get rid of jars in our CVS, we could use something like
http://www.krysalis.org/ruper/ or
http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168.
Ant 1.6 has the ability to import build files which could help to spread
the load.
Don
On Wed, 1 Oct 2003, Robert Leland wrote:
> The whole Maven idea came because we felt the build
> process of ant struts-legacy was broken or needed some
> serious work. If Don wants to put energy into redoing our site's look
> and feel that then here is my +1. Just know we are still
> left with the original problem.
>
> -Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Robert Leland <rl...@apache.org>.
The whole Maven idea came because we felt the build
process of ant struts-legacy was broken or needed some
serious work. If Don wants to put energy into redoing our site's look
and feel that then here is my +1. Just know we are still
left with the original problem.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> Don,
>
> I have one request and that is to leave the existing maven files
> in place since they do currently generate a web site with the reports.
I must be confused with the several projects I'm working on. So, Maven is
already setup in Struts to run the builds? If so, why are we going to add
Forrest to the builds? Why not just start building the site and distro
with Maven?
David
>
> Craig R. McClanahan wrote:
>
> > Don Brown wrote:
> >
> >> I know the discussion on whether to use Forrest or Maven to generate
> the
> >> Struts website was a few weeks back, but unfortunately, at the time,
> >> I was
> >> too busy to participate. I'd like to lay out a case for Forrest, not
> to
> >> insist Struts uses it, but rather to make sure the decision is made
> with
> >> all the available information.
> >>
> >> In short, Forrest offers these benefits over Maven's website
> generation:
> >>
> >> - Multiple output formats including PDF and HTML
> >> - SVG to PNG rendering
> >> - Built for handling and aggregating multiple XML sources like RRS
> (soon
> >> wiki and Docbook)
> >> - Power and features of Cocoon including charting, web services
> >> integration, scripting support, etc.
> >>
> >> Further, deciding between Forrest and Maven isn't an either/or
> >> situation.
> >> There exists a Forrest plugin for Maven and it would be easy to
> >> integrate
> >> Maven's reports into a Forrest site build.
> >>
> >> To me, the key feature of Forrest is the first one listed, multiple
> >> outputs. This is especially useful for documentation as PDF is much
> >> better than HTML for printing for the many users that like hard
> copies.
> >>
> >> Finally, Forrest content is built to be presented in not only
> multiple
> >> output formats, but multiple skins. To demonstrate this, I've
> quickly
> >> redone the Struts site into Forrest format (which is very similiar to
>
> >> the
> >> current format thanks to the xhtml work of late). I've only
> >> converted the
> >> menu and the main page, which should be sufficient.
> >>
> >> Please note, this examples are not polished and only serve to
> >> demonstrate
> >> the skinability of Forrest.
> >>
> >> Krysalis style: http://www.twdata.org/dakine/site/
> >> Avalon/Tigris style: http://www.twdata.org/dakine/site1/
> >> Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
> >>
> >> If we did decide to go with Forrest, I'm willing to convert the old
> site
> >> over and help handle any integration. I'm most definately not an
> expert
> >> at Forrest, but am familiar with Cocoon and thankfully, Forrest is
> >> pretty
> >> easy.
> >>
> >>
> > Looking at the potential here, I'm inclined to suggest we accept Don's
>
> > offer to help set this up -- although perhaps at first in a standalone
>
> > directory structure that can be undone if we discover that we don't
> > like it. One advantage is that we can do it without having to migrate
>
> > the build system to Maven first.
> >
> > As for skins, I sure like the Avalon/Tigris or Krysalis examples, and
> > sure wonder why the Forrest developers chose the native style they
> > ship with, when they could do something as nice looking as either of
> > these. But, if I understand what you're saying, skins is essentially
> > a runtime (when you're generating the HTML) choice; we don't have to
> > make an irrevocable decision at any point in time.
> >
> >> Don
> >>
> >>
> > Craig
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Robert Leland <rl...@apache.org>.
Don,
I have one request and that is to leave the existing maven files
in place since they do currently generate a web site with the reports.
Craig R. McClanahan wrote:
> Don Brown wrote:
>
>> I know the discussion on whether to use Forrest or Maven to generate the
>> Struts website was a few weeks back, but unfortunately, at the time,
>> I was
>> too busy to participate. I'd like to lay out a case for Forrest, not to
>> insist Struts uses it, but rather to make sure the decision is made with
>> all the available information.
>>
>> In short, Forrest offers these benefits over Maven's website generation:
>>
>> - Multiple output formats including PDF and HTML
>> - SVG to PNG rendering
>> - Built for handling and aggregating multiple XML sources like RRS (soon
>> wiki and Docbook)
>> - Power and features of Cocoon including charting, web services
>> integration, scripting support, etc.
>>
>> Further, deciding between Forrest and Maven isn't an either/or
>> situation.
>> There exists a Forrest plugin for Maven and it would be easy to
>> integrate
>> Maven's reports into a Forrest site build.
>>
>> To me, the key feature of Forrest is the first one listed, multiple
>> outputs. This is especially useful for documentation as PDF is much
>> better than HTML for printing for the many users that like hard copies.
>>
>> Finally, Forrest content is built to be presented in not only multiple
>> output formats, but multiple skins. To demonstrate this, I've quickly
>> redone the Struts site into Forrest format (which is very similiar to
>> the
>> current format thanks to the xhtml work of late). I've only
>> converted the
>> menu and the main page, which should be sufficient.
>>
>> Please note, this examples are not polished and only serve to
>> demonstrate
>> the skinability of Forrest.
>>
>> Krysalis style: http://www.twdata.org/dakine/site/
>> Avalon/Tigris style: http://www.twdata.org/dakine/site1/
>> Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
>>
>> If we did decide to go with Forrest, I'm willing to convert the old site
>> over and help handle any integration. I'm most definately not an expert
>> at Forrest, but am familiar with Cocoon and thankfully, Forrest is
>> pretty
>> easy.
>>
>>
> Looking at the potential here, I'm inclined to suggest we accept Don's
> offer to help set this up -- although perhaps at first in a standalone
> directory structure that can be undone if we discover that we don't
> like it. One advantage is that we can do it without having to migrate
> the build system to Maven first.
>
> As for skins, I sure like the Avalon/Tigris or Krysalis examples, and
> sure wonder why the Forrest developers chose the native style they
> ship with, when they could do something as nice looking as either of
> these. But, if I understand what you're saying, skins is essentially
> a runtime (when you're generating the HTML) choice; we don't have to
> make an irrevocable decision at any point in time.
>
>> Don
>>
>>
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Don Brown wrote:
>I know the discussion on whether to use Forrest or Maven to generate the
>Struts website was a few weeks back, but unfortunately, at the time, I was
>too busy to participate. I'd like to lay out a case for Forrest, not to
>insist Struts uses it, but rather to make sure the decision is made with
>all the available information.
>
>In short, Forrest offers these benefits over Maven's website generation:
>
> - Multiple output formats including PDF and HTML
> - SVG to PNG rendering
> - Built for handling and aggregating multiple XML sources like RRS (soon
>wiki and Docbook)
> - Power and features of Cocoon including charting, web services
>integration, scripting support, etc.
>
>Further, deciding between Forrest and Maven isn't an either/or situation.
>There exists a Forrest plugin for Maven and it would be easy to integrate
>Maven's reports into a Forrest site build.
>
>To me, the key feature of Forrest is the first one listed, multiple
>outputs. This is especially useful for documentation as PDF is much
>better than HTML for printing for the many users that like hard copies.
>
>Finally, Forrest content is built to be presented in not only multiple
>output formats, but multiple skins. To demonstrate this, I've quickly
>redone the Struts site into Forrest format (which is very similiar to the
>current format thanks to the xhtml work of late). I've only converted the
>menu and the main page, which should be sufficient.
>
>Please note, this examples are not polished and only serve to demonstrate
>the skinability of Forrest.
>
>Krysalis style: http://www.twdata.org/dakine/site/
>Avalon/Tigris style: http://www.twdata.org/dakine/site1/
>Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
>
>If we did decide to go with Forrest, I'm willing to convert the old site
>over and help handle any integration. I'm most definately not an expert
>at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
>easy.
>
>
Looking at the potential here, I'm inclined to suggest we accept Don's
offer to help set this up -- although perhaps at first in a standalone
directory structure that can be undone if we discover that we don't like
it. One advantage is that we can do it without having to migrate the
build system to Maven first.
As for skins, I sure like the Avalon/Tigris or Krysalis examples, and
sure wonder why the Forrest developers chose the native style they ship
with, when they could do something as nice looking as either of these.
But, if I understand what you're saying, skins is essentially a runtime
(when you're generating the HTML) choice; we don't have to make an
irrevocable decision at any point in time.
>Don
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>
>The Forrest features Don mentioned aren't significant to me and I'm
>already familiar with Maven so I'm leaning towards Maven but I really
>don't care as long as the build is as easy as "maven jar" or equivalent.
>But please let's not try to maintain multiple build processes.
>
>
I was looking at the Forrest archives and it looks like they are in the
early stages of creating
a build system. Until that time then it we have the choices of Maven,
Maven + Forrest, or Forrest + Ant.
>David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
Option]
Posted by Don Brown <mr...@twdata.org>.
It might be broken, but then again, we aren't using Maven today anyways.
I asked him about it, and he said last he heard it was working, some
people reported it buggy, but since no one was using it, it was staying
in jira until someone could put time into it. If we moved to Forrest, I
would certainly put time in fixing it and getting it added to Maven's
repository.
Don
On Thu, 2 Oct 2003, Robert Leland wrote:
> James Mitchell wrote:
>
> I thought that one of the Forrest Committters said that the Forrest
> plug-in for Maven
> is most likely broken ?
>
> >Most of us have given (or at least hinted at) our opinions, so let's give a
> >show of hands:
> >
> >Mavenization:
> >[X] +1 - I am in favor of using Maven for build/dist/test/etc.
> >[ ] +0 - I agree, but cannot help at this time.
> >[ ] -0 - I don't agree, but not enough to give a -1.
> >[ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
> >
> >Forrestization:
> >[X] +1 - I am in favor of using Forrest for site generation.
> >[ ] +0 - I agree, but cannot help at this time.
> >[ ] -0 - I don't agree, but not enough to give a -1.
> >[ ] -1 - I am not in favor of using Forrest for site generation.
> >
> >Other:
> >[X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
> >
> >
> >(If I left out any, please add them)
> >
> >
> >
> >One question I have about all this, (and please forgive me if I missed it in
> >any of the messages in this thread) how does using either approach affect
> >the generation of the .tld from our source?
> >
> >
> >
> >
> >--
> >James Mitchell
> >Software Engineer / Struts Evangelist
> >http://www.struts-atlanta.org
> >678.910.8017
> >770.822.3359
> >AIM:jmitchtx
> >
> >
> >
> >----- Original Message -----
> >From: "Don Brown" <mr...@twdata.org>
> >To: "Struts Developers List" <st...@jakarta.apache.org>
> >Sent: Wednesday, October 01, 2003 7:18 PM
> >Subject: Re: The Forrest Option
> >
> >
> >
> >
> >>On Wed, 1 Oct 2003, Craig R. McClanahan wrote:
> >><snip />
> >>
> >>
> >>><ducks>
> >>>We can even add Forrest-based generation to our current Ant-based build
> >>>scripts :-). It's just an external tool, after all.
> >>></ducks>
> >>>
> >>>
> >>Actually it is very easy to do, using a forrest entity which imports
> >>forrest targets. The only setup needed is to install forrest and set
> >>FORREST_HOME. All the same ant targets used now to build the site can be
> >>used to build forrest. If the Forrest route was accepted, I planned to do
> >>this from the start.
> >>
> >>Don
> >>
> >>
> >>
> >>>>There's only so much time we each have to spend on Struts. I'd rather
> >>>>
> >>>>
> >not
> >
> >
> >>>>spend much time learning the build process.
> >>>>
> >>>>David
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Craig
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
Option]
Posted by Robert Leland <rl...@apache.org>.
James Mitchell wrote:
I thought that one of the Forrest Committters said that the Forrest
plug-in for Maven
is most likely broken ?
>Most of us have given (or at least hinted at) our opinions, so let's give a
>show of hands:
>
>Mavenization:
>[X] +1 - I am in favor of using Maven for build/dist/test/etc.
>[ ] +0 - I agree, but cannot help at this time.
>[ ] -0 - I don't agree, but not enough to give a -1.
>[ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>
>Forrestization:
>[X] +1 - I am in favor of using Forrest for site generation.
>[ ] +0 - I agree, but cannot help at this time.
>[ ] -0 - I don't agree, but not enough to give a -1.
>[ ] -1 - I am not in favor of using Forrest for site generation.
>
>Other:
>[X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>
>
>(If I left out any, please add them)
>
>
>
>One question I have about all this, (and please forgive me if I missed it in
>any of the messages in this thread) how does using either approach affect
>the generation of the .tld from our source?
>
>
>
>
>--
>James Mitchell
>Software Engineer / Struts Evangelist
>http://www.struts-atlanta.org
>678.910.8017
>770.822.3359
>AIM:jmitchtx
>
>
>
>----- Original Message -----
>From: "Don Brown" <mr...@twdata.org>
>To: "Struts Developers List" <st...@jakarta.apache.org>
>Sent: Wednesday, October 01, 2003 7:18 PM
>Subject: Re: The Forrest Option
>
>
>
>
>>On Wed, 1 Oct 2003, Craig R. McClanahan wrote:
>><snip />
>>
>>
>>><ducks>
>>>We can even add Forrest-based generation to our current Ant-based build
>>>scripts :-). It's just an external tool, after all.
>>></ducks>
>>>
>>>
>>Actually it is very easy to do, using a forrest entity which imports
>>forrest targets. The only setup needed is to install forrest and set
>>FORREST_HOME. All the same ant targets used now to build the site can be
>>used to build forrest. If the Forrest route was accepted, I planned to do
>>this from the start.
>>
>>Don
>>
>>
>>
>>>>There's only so much time we each have to spend on Struts. I'd rather
>>>>
>>>>
>not
>
>
>>>>spend much time learning the build process.
>>>>
>>>>David
>>>>
>>>>
>>>>
>>>>
>>>Craig
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
Option]
Posted by Don Brown <mr...@twdata.org>.
I believe the question is not between maven and forrest, but rather
between Anakia/xdoc and forrest. It is entirely possible to even use all
the report output from Maven and include it in a forrest build of the
website. Default Maven uses the xdoc plugin. All forrest would be doing
is replacing it with the Forrst plugin. You would still be able to get
all the Maven-generated content.
Forrest is not a built tool. It only replaces xdoc whether we keep Ant or
go to Maven.
Could this vote not be redone?
Mavenization with xdoc plugin:
[ ] +1 - I am in favor of using Maven and the xdoc plugin
[ ] +0 - I agree, but cannot help at this time.
[ ] -0 - I don't agree, but not enough to give a -1.
[ ] -1 - I am not in favor of using the xdoc plugin
Mavenization with the Forrest plugin:
[ ] +1 - I am in favor of using Forrest instead of xdoc.
[ ] +0 - I agree, but cannot help at this time.
[ ] -0 - I don't agree, but not enough to give a -1.
[ ] -1 - I am not in favor of using Forrest instead of xdoc.
I'm assuming a move to Maven is inevitable?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
Option]
Posted by Robert Leland <rl...@apache.org>.
Steve Raeburn wrote:
>Well Rob has already made a start on adding Maven. I did try building with
>it, but hit a snag downloading the validator jar and I've not had a chance
>to have another look since.
>
>
Typically, an request is posted on the developers list requestiong that
a jar be uploaded to
their repository. I'll do that now.
I would like ot see Maven all the way but since this isn't part of core
Struts then I feel I don't
have a real right to vote -1, it's not life or death.
I agree if Don wants to 'roll' their sleeves up and do Forrest then Ok.
If someone want's to roll their sleeves up and do maven than that's good
also.
My guess is that putting the struts docs in Maven/Forrest would take
about the same amount of time.
Menu entries are placed in the navigation.xml file and it flows down
from there.
It could be as easy as copying all the .xml files from doc -> xdoc,
though I believe the
XML element names might have to change.
As far as stability, Maven is very stable. I had been running off the
CVS HEAD for a while.
I believe they are going to come out with RC2 in the next few weeks,
they were talking about this
weekend, but nothing ever happens that quickly. Of course the project
leader Jason is back from
an extended leave so who knows.
Again if there are no Volunteers stepping up for Maven and Don wants to
mover over to Forrest
then +1.
-Rob
>I wouldn't have a problem with releasing based on a Maven RC because it's
>not a run-time dependency. Having said that I would consider our use of
>Maven to be experimental for a while, until we get more familiar with it,
>and run it in parallel with the current Ant build. I'm sure that before too
>long it will become obvious whether the experiment has succeeded or not.
>
>Steve
>
>
>
>
>
>>-----Original Message-----
>>From: Ted Husted [mailto:husted@apache.org]
>>Sent: October 2, 2003 10:18 AM
>>To: Struts Developers List
>>Subject: Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The
>>Forrest Option]
>>
>>
>>Steve Raeburn wrote:
>> > I'd like to add Maven now, learn from the experience on 1.x and then
>> > use that to optimize the project organization and build process for
>> > version 2.
>>
>>If the people voting +1 are ready to roll up their collective sleeves
>>and give Maven a try, then that would be fine with me. The missing piece
>>has been someone saying "I'm ready to do Maven *now*".
>>
>>My only concern is that Maven has not had a stable release. After ten
>>betas, it has just published a RC1, but that's still shy of 1.0.
>>
>>During the 1.1 incubation period, we withheld making a final release
>>until all our dependent JARs were also in a final release state. But,
>>since Maven is a production environment, and not a JAR teams would need
>>to include in their own releases, this consideration might not apply.
>>
>>So, if we would be able to ship a GA of Struts with a Maven Release
>>Candidate, then I'm fine with whatever anyone wants to do.
>>
>>But, if anyone is going to vote against a Struts GA on the grounds that
>>Maven is prerelease, then we should wait until Maven hits 1.0.
>>
>>I don't mind waiting on the Commons Validator, but I wouldn't want to
>>wait on Maven.
>>
>>-Ted.
>>
>>
>>Don Brown wrote:
>> > I'm assuming a move to Maven is inevitable?
>>
>>"You will be assimilated."
>>
>>
>>
>>James Mitchell wrote:
>> > Mavenization:
>> > [ ] +1 - I am in favor of using Maven for build/dist/test/etc.
>> > [X] +0 - I agree, but cannot help at this time.
>> > [ ] -0 - I don't agree, but not enough to give a -1.
>> > [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>> >
>> > Forrestization:
>> > [ ] +1 - I am in favor of using Forrest for site generation.
>> > [X] +0 - I agree, but cannot help at this time.
>> > [ ] -0 - I don't agree, but not enough to give a -1.
>> > [ ] -1 - I am not in favor of using Forrest for site generation.
>> >
>> > Other:
>> > [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The
Forrest Option]
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:04 -0700 10/2/03, Steve Raeburn wrote:
>Well Rob has already made a start on adding Maven. I did try building with
>it, but hit a snag downloading the validator jar and I've not had a chance
>to have another look since.
The snag is that commons-validator-1.1.0.jar is not on the default
(iBiblio) repository. If you get a copy in your own maven
repository, you'll be fine. (I just put in a formal request to have
it uploaded, ref:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-879)
If you have the binary for the jar, you can just drop it in your
local repository (on UNIX systems, that would normally be
~/.maven/repository/commons-logging/jars/ -- not real sure for
Windows.)
In theory, you should be able to check out commons-validator from CVS
and install it using "maven jar:install", but I was having problems
with tests last time I tried (weeks ago). You could use "maven
-Dmaven.test.failure.ignore=true jar:install" instead.
Once that's installed, maven java:compile works file for the current
CVS repository of Struts. Yesterday I had trouble with "maven site".
I'm hoping to provide some energy to help Rob, but I'm on a deadline
this week and next. I actually don't have much Maven experience on
something as large as this -- Rob is forging out into the new Maven
"multiproject" plugin, which I hope to learn about but haven't yet...
It's still premature to drop the Ant build, but Maven is ready for
use, say if you want to use it to set up an IDE project in Eclipse,
JBuilder or IDEA, and like I said, for compiling. Actually, I'd be
better able to help if people started posting bugs about it... so
i'd say "dive in!" It's pretty non-invasive.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
Posted by Steve Raeburn <sr...@apache.org>.
Well Rob has already made a start on adding Maven. I did try building with
it, but hit a snag downloading the validator jar and I've not had a chance
to have another look since.
I wouldn't have a problem with releasing based on a Maven RC because it's
not a run-time dependency. Having said that I would consider our use of
Maven to be experimental for a while, until we get more familiar with it,
and run it in parallel with the current Ant build. I'm sure that before too
long it will become obvious whether the experiment has succeeded or not.
Steve
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: October 2, 2003 10:18 AM
> To: Struts Developers List
> Subject: Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The
> Forrest Option]
>
>
> Steve Raeburn wrote:
> > I'd like to add Maven now, learn from the experience on 1.x and then
> > use that to optimize the project organization and build process for
> > version 2.
>
> If the people voting +1 are ready to roll up their collective sleeves
> and give Maven a try, then that would be fine with me. The missing piece
> has been someone saying "I'm ready to do Maven *now*".
>
> My only concern is that Maven has not had a stable release. After ten
> betas, it has just published a RC1, but that's still shy of 1.0.
>
> During the 1.1 incubation period, we withheld making a final release
> until all our dependent JARs were also in a final release state. But,
> since Maven is a production environment, and not a JAR teams would need
> to include in their own releases, this consideration might not apply.
>
> So, if we would be able to ship a GA of Struts with a Maven Release
> Candidate, then I'm fine with whatever anyone wants to do.
>
> But, if anyone is going to vote against a Struts GA on the grounds that
> Maven is prerelease, then we should wait until Maven hits 1.0.
>
> I don't mind waiting on the Commons Validator, but I wouldn't want to
> wait on Maven.
>
> -Ted.
>
>
> Don Brown wrote:
> > I'm assuming a move to Maven is inevitable?
>
> "You will be assimilated."
>
>
>
> James Mitchell wrote:
> > Mavenization:
> > [ ] +1 - I am in favor of using Maven for build/dist/test/etc.
> > [X] +0 - I agree, but cannot help at this time.
> > [ ] -0 - I don't agree, but not enough to give a -1.
> > [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
> >
> > Forrestization:
> > [ ] +1 - I am in favor of using Forrest for site generation.
> > [X] +0 - I agree, but cannot help at this time.
> > [ ] -0 - I don't agree, but not enough to give a -1.
> > [ ] -1 - I am not in favor of using Forrest for site generation.
> >
> > Other:
> > [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
Option]
Posted by Ted Husted <hu...@apache.org>.
Steve Raeburn wrote:
> I'd like to add Maven now, learn from the experience on 1.x and then
> use that to optimize the project organization and build process for
> version 2.
If the people voting +1 are ready to roll up their collective sleeves
and give Maven a try, then that would be fine with me. The missing piece
has been someone saying "I'm ready to do Maven *now*".
My only concern is that Maven has not had a stable release. After ten
betas, it has just published a RC1, but that's still shy of 1.0.
During the 1.1 incubation period, we withheld making a final release
until all our dependent JARs were also in a final release state. But,
since Maven is a production environment, and not a JAR teams would need
to include in their own releases, this consideration might not apply.
So, if we would be able to ship a GA of Struts with a Maven Release
Candidate, then I'm fine with whatever anyone wants to do.
But, if anyone is going to vote against a Struts GA on the grounds that
Maven is prerelease, then we should wait until Maven hits 1.0.
I don't mind waiting on the Commons Validator, but I wouldn't want to
wait on Maven.
-Ted.
Don Brown wrote:
> I'm assuming a move to Maven is inevitable?
"You will be assimilated."
James Mitchell wrote:
> Mavenization:
> [ ] +1 - I am in favor of using Maven for build/dist/test/etc.
> [X] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>
> Forrestization:
> [ ] +1 - I am in favor of using Forrest for site generation.
> [X] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Forrest for site generation.
>
> Other:
> [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
Posted by Steve Raeburn <sr...@apache.org>.
Maven: +1
Forrest: -0
Forrest plug-in: Possibly, but not yet.
I'm more interested in streamlining the build and I don't consider the
website production to be broken, so Forrest is not a big priority for me.
I'm not saying never, but I see Maven as more of a priority and would rather
wait and see on Forrest.
I'd like to add Maven now, learn from the experience on 1.x and then use
that to optimize the project organization and build process for version 2.
Steve
> -----Original Message-----
> From: James Mitchell [mailto:jmitchell@apache.org]
> Sent: October 1, 2003 9:58 PM
> To: Struts Developers List
> Subject: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
> Option]
>
>
> Most of us have given (or at least hinted at) our opinions, so
> let's give a
> show of hands:
>
> Mavenization:
> [X] +1 - I am in favor of using Maven for build/dist/test/etc.
> [ ] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>
> Forrestization:
> [X] +1 - I am in favor of using Forrest for site generation.
> [ ] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Forrest for site generation.
>
> Other:
> [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>
>
> (If I left out any, please add them)
>
>
>
> One question I have about all this, (and please forgive me if I
> missed it in
> any of the messages in this thread) how does using either approach affect
> the generation of the .tld from our source?
>
>
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> 770.822.3359
> AIM:jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
[Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
Posted by James Mitchell <jm...@apache.org>.
Most of us have given (or at least hinted at) our opinions, so let's give a
show of hands:
Mavenization:
[X] +1 - I am in favor of using Maven for build/dist/test/etc.
[ ] +0 - I agree, but cannot help at this time.
[ ] -0 - I don't agree, but not enough to give a -1.
[ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
Forrestization:
[X] +1 - I am in favor of using Forrest for site generation.
[ ] +0 - I agree, but cannot help at this time.
[ ] -0 - I don't agree, but not enough to give a -1.
[ ] -1 - I am not in favor of using Forrest for site generation.
Other:
[X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
(If I left out any, please add them)
One question I have about all this, (and please forgive me if I missed it in
any of the messages in this thread) how does using either approach affect
the generation of the .tld from our source?
--
James Mitchell
Software Engineer / Struts Evangelist
http://www.struts-atlanta.org
678.910.8017
770.822.3359
AIM:jmitchtx
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, October 01, 2003 7:18 PM
Subject: Re: The Forrest Option
> On Wed, 1 Oct 2003, Craig R. McClanahan wrote:
> <snip />
> > <ducks>
> > We can even add Forrest-based generation to our current Ant-based build
> > scripts :-). It's just an external tool, after all.
> > </ducks>
>
> Actually it is very easy to do, using a forrest entity which imports
> forrest targets. The only setup needed is to install forrest and set
> FORREST_HOME. All the same ant targets used now to build the site can be
> used to build forrest. If the Forrest route was accepted, I planned to do
> this from the start.
>
> Don
>
> >
> > >There's only so much time we each have to spend on Struts. I'd rather
not
> > >spend much time learning the build process.
> > >
> > >David
> > >
> > >
> > Craig
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Don Brown <mr...@twdata.org>.
On Wed, 1 Oct 2003, Craig R. McClanahan wrote:
<snip />
> <ducks>
> We can even add Forrest-based generation to our current Ant-based build
> scripts :-). It's just an external tool, after all.
> </ducks>
Actually it is very easy to do, using a forrest entity which imports
forrest targets. The only setup needed is to install forrest and set
FORREST_HOME. All the same ant targets used now to build the site can be
used to build forrest. If the Forrest route was accepted, I planned to do
this from the start.
Don
>
> >There's only so much time we each have to spend on Struts. I'd rather not
> >spend much time learning the build process.
> >
> >David
> >
> >
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by "Craig R. McClanahan" <cr...@apache.org>.
David Graham wrote:
>--- Ted Husted <hu...@apache.org> wrote:
>
>
>>David Graham wrote:
>>
>>
>>>Rob mentioned something about Struts being setup for Maven already and
>>>
>>>
>>I
>>
>>
>>>asked for clarification. If that's true then I see no point in
>>>complicating things with another build tool. Also, it seems that
>>>
>>>
>>Maven in
>>
>>
>>>some ways is a superset of Forrest functionality. It handles the
>>>
>>>
>>website
>>
>>
>>>plus the jar builds.
>>>
>>>The more tools involved means it's harder to understand the build
>>>
>>>
>>process
>>
>>
>>>which limits the number of people willing to put up with it and work
>>>
>>>
>>on
>>
>>
>>>Struts. My personal goal (and I hope the group's as well) is to have
>>>*one* easy to use tool that builds all of Struts. I don't care if
>>>
>>>
>>this is
>>
>>
>>>Ant, Maven, or Forrest as long as it's only one of them.
>>>
>>>David
>>>
>>>
>>Yes, but the goals around here are achieved by people willing to do the
>>work.
>>
>>
>
>I agree with you but it would be nice to have some kind of consensus
>around the direction the build is going.
>
>I trust Don's judgement that Forrest is a good tool to use but I didn't
>want the build to increase in complexity. We can apparently plug Forrest
>into a Maven build which I think is great.
>
>
<ducks>
We can even add Forrest-based generation to our current Ant-based build
scripts :-). It's just an external tool, after all.
</ducks>
>There's only so much time we each have to spend on Struts. I'd rather not
>spend much time learning the build process.
>
>David
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> David Graham wrote:
> > Rob mentioned something about Struts being setup for Maven already and
> I
> > asked for clarification. If that's true then I see no point in
> > complicating things with another build tool. Also, it seems that
> Maven in
> > some ways is a superset of Forrest functionality. It handles the
> website
> > plus the jar builds.
> >
> > The more tools involved means it's harder to understand the build
> process
> > which limits the number of people willing to put up with it and work
> on
> > Struts. My personal goal (and I hope the group's as well) is to have
> > *one* easy to use tool that builds all of Struts. I don't care if
> this is
> > Ant, Maven, or Forrest as long as it's only one of them.
> >
> > David
>
> Yes, but the goals around here are achieved by people willing to do the
> work.
I agree with you but it would be nice to have some kind of consensus
around the direction the build is going.
I trust Don's judgement that Forrest is a good tool to use but I didn't
want the build to increase in complexity. We can apparently plug Forrest
into a Maven build which I think is great.
There's only so much time we each have to spend on Struts. I'd rather not
spend much time learning the build process.
David
>
> If Rob wants to do the work of migrating to Maven, for whatever reason,
> that's fine with me. A lot of people I respect use Maven, it can't suck
> that badly. If Don wants to do the work of migrating to Forrest, that's
> fine too. A lot of people I respect use Forrest, so it can't suck that
> badly either.
>
> But, if we're just looking for a "one-tool solution that builds all of
> Struts", we already have one. To change a page in the docs, you edit the
>
> corresponding XML page. To add to the menu, edit the project.xml for
> that directory. Run the Ant target. Done.
>
> If we want Struts to be even easier to build for newbies, then we should
>
> bring back the struts-lib distribution. Download that with the source,
> and you were ready to rock.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> Rob mentioned something about Struts being setup for Maven already and I
> asked for clarification. If that's true then I see no point in
> complicating things with another build tool. Also, it seems that Maven in
> some ways is a superset of Forrest functionality. It handles the website
> plus the jar builds.
>
> The more tools involved means it's harder to understand the build process
> which limits the number of people willing to put up with it and work on
> Struts. My personal goal (and I hope the group's as well) is to have
> *one* easy to use tool that builds all of Struts. I don't care if this is
> Ant, Maven, or Forrest as long as it's only one of them.
>
> David
Yes, but the goals around here are achieved by people willing to do the
work.
If Rob wants to do the work of migrating to Maven, for whatever reason,
that's fine with me. A lot of people I respect use Maven, it can't suck
that badly. If Don wants to do the work of migrating to Forrest, that's
fine too. A lot of people I respect use Forrest, so it can't suck that
badly either.
But, if we're just looking for a "one-tool solution that builds all of
Struts", we already have one. To change a page in the docs, you edit the
corresponding XML page. To add to the menu, edit the project.xml for
that directory. Run the Ant target. Done.
If we want Struts to be even easier to build for newbies, then we should
bring back the struts-lib distribution. Download that with the source,
and you were ready to rock.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
--- Don Brown <mr...@twdata.org> wrote:
> On Wed, 1 Oct 2003, David Graham wrote:
> <snip />
> > Rob mentioned something about Struts being setup for Maven already and
> I
> > asked for clarification. If that's true then I see no point in
> > complicating things with another build tool. Also, it seems that
> Maven in
> > some ways is a superset of Forrest functionality. It handles the
> website
> > plus the jar builds.
>
> Forrest is not a build tool. If we went with Maven, Forrest would just
> be
> another plugin, just like most people use the default site building
> plugin.
>
> > The more tools involved means it's harder to understand the build
> process
> > which limits the number of people willing to put up with it and work
> on
> > Struts. My personal goal (and I hope the group's as well) is to have
> > *one* easy to use tool that builds all of Struts. I don't care if
> this is
> > Ant, Maven, or Forrest as long as it's only one of them.
>
> I agree, but if a Forrest plugin for Maven is used, you still use one
> tool
> to build all of Struts.
Great, that sounds like we can get the features of Forrest while still
using one tool. Thanks for the explanation.
David
>
> Don
>
> >
> > David
> >
> > >
> > > Though, a valid, technical objection would be that the website and
> the
> > > build (except for the current Cactus snafu) ain't broke, so we don't
> > > need to fix it. Steve's got everything running as valid XHTML. We're
> > > still using the original Apache look, but then so is the vast
> majority
> > > of other Apache projects. If we dusted off the struts-lib
> distribution
> > > (which appeared and disappeared during the last beta cycle), the
> > > quick-start concerns would be answered.
> > >
> > > Certainly, it would make sense to start new development on Forrest
> > > and/or Maven. If we spun off taglibs or rolled up our sleeves on
> 2.0,
> > > then we'd definitely want to make a decision there. (Based primarily
> on
> > > who was willing to do the work.)
> > >
> > > And, we do have Forrest running on the SourceForge site, so things
> like
> > > RSS feeds and WikiDocs could be tried there first to see how helpful
> > > they really are. (I must admit, I'm intrigued.)
> > >
> > > -Ted.
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Don Brown <mr...@twdata.org>.
On Wed, 1 Oct 2003, David Graham wrote:
<snip />
> Rob mentioned something about Struts being setup for Maven already and I
> asked for clarification. If that's true then I see no point in
> complicating things with another build tool. Also, it seems that Maven in
> some ways is a superset of Forrest functionality. It handles the website
> plus the jar builds.
Forrest is not a build tool. If we went with Maven, Forrest would just be
another plugin, just like most people use the default site building
plugin.
> The more tools involved means it's harder to understand the build process
> which limits the number of people willing to put up with it and work on
> Struts. My personal goal (and I hope the group's as well) is to have
> *one* easy to use tool that builds all of Struts. I don't care if this is
> Ant, Maven, or Forrest as long as it's only one of them.
I agree, but if a Forrest plugin for Maven is used, you still use one tool
to build all of Struts.
Don
>
> David
>
> >
> > Though, a valid, technical objection would be that the website and the
> > build (except for the current Cactus snafu) ain't broke, so we don't
> > need to fix it. Steve's got everything running as valid XHTML. We're
> > still using the original Apache look, but then so is the vast majority
> > of other Apache projects. If we dusted off the struts-lib distribution
> > (which appeared and disappeared during the last beta cycle), the
> > quick-start concerns would be answered.
> >
> > Certainly, it would make sense to start new development on Forrest
> > and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0,
> > then we'd definitely want to make a decision there. (Based primarily on
> > who was willing to do the work.)
> >
> > And, we do have Forrest running on the SourceForge site, so things like
> > RSS feeds and WikiDocs could be tried there first to see how helpful
> > they really are. (I must admit, I'm intrigued.)
> >
> > -Ted.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> Chris Gastin wrote:
> > I have to agree with David. Lets find one way to do it and make it
> simple,
> > if a build process can be. I have worked a little with Maven, and it
> seems
> > tobe simple. I am not knocking Forrest. I have not had a chance to
> look into
> > it. If that is more simple than Maven then I am all for it. Lets not
> make
> > the build process this awful process. I think everyone would agree
> with
> > that.
>
> We're not talking about the build process as a whole. The Forrest Option
>
> refers only to website maintenance and documentation.
>
> Since Don's ready to sign-up for Forrest, we should start by trusting
> his judgment and be ready to give this a try. That's what it means to be
>
> a Committer. Make the decision, do the work.
>
> At this point, no one is raising their hand and offering to migrate us
> to Maven. Until someone does, Maven does not seem like a valid
> objection.
Rob mentioned something about Struts being setup for Maven already and I
asked for clarification. If that's true then I see no point in
complicating things with another build tool. Also, it seems that Maven in
some ways is a superset of Forrest functionality. It handles the website
plus the jar builds.
The more tools involved means it's harder to understand the build process
which limits the number of people willing to put up with it and work on
Struts. My personal goal (and I hope the group's as well) is to have
*one* easy to use tool that builds all of Struts. I don't care if this is
Ant, Maven, or Forrest as long as it's only one of them.
David
>
> Though, a valid, technical objection would be that the website and the
> build (except for the current Cactus snafu) ain't broke, so we don't
> need to fix it. Steve's got everything running as valid XHTML. We're
> still using the original Apache look, but then so is the vast majority
> of other Apache projects. If we dusted off the struts-lib distribution
> (which appeared and disappeared during the last beta cycle), the
> quick-start concerns would be answered.
>
> Certainly, it would make sense to start new development on Forrest
> and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0,
> then we'd definitely want to make a decision there. (Based primarily on
> who was willing to do the work.)
>
> And, we do have Forrest running on the SourceForge site, so things like
> RSS feeds and WikiDocs could be tried there first to see how helpful
> they really are. (I must admit, I'm intrigued.)
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Ted Husted <hu...@apache.org>.
Chris Gastin wrote:
> I have to agree with David. Lets find one way to do it and make it simple,
> if a build process can be. I have worked a little with Maven, and it seems
> tobe simple. I am not knocking Forrest. I have not had a chance to look into
> it. If that is more simple than Maven then I am all for it. Lets not make
> the build process this awful process. I think everyone would agree with
> that.
We're not talking about the build process as a whole. The Forrest Option
refers only to website maintenance and documentation.
Since Don's ready to sign-up for Forrest, we should start by trusting
his judgment and be ready to give this a try. That's what it means to be
a Committer. Make the decision, do the work.
At this point, no one is raising their hand and offering to migrate us
to Maven. Until someone does, Maven does not seem like a valid objection.
Though, a valid, technical objection would be that the website and the
build (except for the current Cactus snafu) ain't broke, so we don't
need to fix it. Steve's got everything running as valid XHTML. We're
still using the original Apache look, but then so is the vast majority
of other Apache projects. If we dusted off the struts-lib distribution
(which appeared and disappeared during the last beta cycle), the
quick-start concerns would be answered.
Certainly, it would make sense to start new development on Forrest
and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0,
then we'd definitely want to make a decision there. (Based primarily on
who was willing to do the work.)
And, we do have Forrest running on the SourceForge site, so things like
RSS feeds and WikiDocs could be tried there first to see how helpful
they really are. (I must admit, I'm intrigued.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Chris Gastin <ch...@gastin.com>.
I have to agree with David. Lets find one way to do it and make it simple,
if a build process can be. I have worked a little with Maven, and it seems
tobe simple. I am not knocking Forrest. I have not had a chance to look into
it. If that is more simple than Maven then I am all for it. Lets not make
the build process this awful process. I think everyone would agree with
that.
Chris Gastin
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, October 01, 2003 8:51 AM
Subject: Re: The Forrest Option
>
> --- Ted Husted <hu...@apache.org> wrote:
> > Don Brown wrote:
> > > Further, deciding between Forrest and Maven isn't an either/or
> > situation.
> > > There exists a Forrest plugin for Maven and it would be easy to
> > integrate
> > > Maven's reports into a Forrest site build.
> >
> > <.../>
> >
> > > If we did decide to go with Forrest, I'm willing to convert the old
> > site
> > > over and help handle any integration. I'm most definately not an
> > expert
> > > at Forrest, but am familiar with Cocoon and thankfully, Forrest is
> > pretty
> > > easy.
> >
> > +1
> >
> > This sounds like a nice stepping stone. We can try Forrest now and
> > migrate the build to Maven as soon as someone is ready to volunteer for
> > that.
> >
> > Outside of the Jakarta Commons Sandbox, Forrest and Maven are equally
> > popular among other Apache products. Using both might be the best of
> > both worlds.
>
> Or it may be a complete nightmare. So then we would have Forrest, Maven,
> and Ant builds all competing for attention. I am definitely against using
> multiple build processes; let's just pick one and stick with it.
>
> The Forrest features Don mentioned aren't significant to me and I'm
> already familiar with Maven so I'm leaning towards Maven but I really
> don't care as long as the build is as easy as "maven jar" or equivalent.
> But please let's not try to maintain multiple build processes.
>
> David
>
> >
> > -Ted.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> Don Brown wrote:
> > Further, deciding between Forrest and Maven isn't an either/or
> situation.
> > There exists a Forrest plugin for Maven and it would be easy to
> integrate
> > Maven's reports into a Forrest site build.
>
> <.../>
>
> > If we did decide to go with Forrest, I'm willing to convert the old
> site
> > over and help handle any integration. I'm most definately not an
> expert
> > at Forrest, but am familiar with Cocoon and thankfully, Forrest is
> pretty
> > easy.
>
> +1
>
> This sounds like a nice stepping stone. We can try Forrest now and
> migrate the build to Maven as soon as someone is ready to volunteer for
> that.
>
> Outside of the Jakarta Commons Sandbox, Forrest and Maven are equally
> popular among other Apache products. Using both might be the best of
> both worlds.
Or it may be a complete nightmare. So then we would have Forrest, Maven,
and Ant builds all competing for attention. I am definitely against using
multiple build processes; let's just pick one and stick with it.
The Forrest features Don mentioned aren't significant to me and I'm
already familiar with Maven so I'm leaning towards Maven but I really
don't care as long as the build is as easy as "maven jar" or equivalent.
But please let's not try to maintain multiple build processes.
David
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Ted Husted <hu...@apache.org>.
Don Brown wrote:
> Further, deciding between Forrest and Maven isn't an either/or situation.
> There exists a Forrest plugin for Maven and it would be easy to integrate
> Maven's reports into a Forrest site build.
<.../>
> If we did decide to go with Forrest, I'm willing to convert the old site
> over and help handle any integration. I'm most definately not an expert
> at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
> easy.
+1
This sounds like a nice stepping stone. We can try Forrest now and
migrate the build to Maven as soon as someone is ready to volunteer for
that.
Outside of the Jakarta Commons Sandbox, Forrest and Maven are equally
popular among other Apache products. Using both might be the best of
both worlds.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Vic Cekvenich <ce...@basebeans.com>.
Don Brown wrote:
<SNIP>
> If we did decide to go with Forrest, I'm willing to convert the old site
> over and help handle any integration.
<SNIP>
AFAIK, that is 90%+ of O.S.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Jeff Turner <je...@apache.org>.
<decloak/>
(it's sad the number of lists I lurk on)
Just thought I'd throw in a few points..
- Forrest is *purely* a documentation tool. It is comparable to Maven's
xdoc plugin, not Maven itself. Compared to the xdoc plugin, it is
bigger, slower, more powerful. Running Forrest feels like firing a
BFG2000 in Quake. Slow build-up, WHOOMPH, casualties everywhere. If
you don't kill yourself, the effects can be impressive.
- Forrest does not assume responsibility for the whole website, just the
parts it renders. So a javadoc link would be added to the menu, but
whatever calls Forrest would have to also call Javadoc.
- Forrest has fine-grained PDF generation (per page or per set of
pages), so you could partition off a section (the user manual for
example) and generate a PDF (or one-page HTML) for just that section.
- Forrest's Maven plugin is mostly unused and probably broken (it's in
Forrest's JIRA if anyone wants to play).
- Forrest is massive (13Mb of Cocoon jars) and command-line rendering
relatively slow. Implies that even if the plugin worked,
'site:generate' could not be a commonly invoked goal.
- Slowness of command-line rendering is irrelevant for daily editing,
because:
- Most people would not need Forrest to develop docs. Forrest
completely separates content from presentation, with strong and
stable contracts between (DTDs). Doc writers can just write XML
content, and if it validates, safely check it in. Rendered results
can be viewed (and committed to jakarta-site) through an online
service like http://forrestbot.cocoondev.org.
- Forrest has a built-in Jetty server, so for writers wanting visual
feedback, edited pages can be rerendered instantly with Cocoon.
- *Lots* of stuff (charting, scripting etc) is possible with Cocoon but
isn't in Forrest until we find a half-decent use-case. Wiki rendering
is so that you can integrate a Wiki's text files into a Forrest-built
site: http://www.apache.org/~jefft/forrest/samples/wikirenderer-site/
The latest thing to be pulled in from Cocoon is Lucene searching.
--Jeff
(Forrest developer / BFG vendor)
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Ted Husted <hu...@apache.org>.
Don Brown wrote:
> For example, currently, we have quite a few Struts extensions, example
> applications, and related frameworks that I feel Struts could do a better
> job of encouraging. Instead of requiring an extension developer to submit
> a patch to bugzilla to change a description or add their project to the
> page, why not have a page that aggregates extension project's RSS
> announcing new releases into a news-type page. Giving extension projects
> more exposure will generate more interest in finding ways to make Struts
> better. Look what it did for Maven :)
How about if we give a wider trial Forrest on the Community section
first? This would be mainly News and Status, Resources, and could also
include a Wiki compilation.
If it doesn't work out, the Community section would be easy enough to
roll back.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Don Brown <mr...@twdata.org>.
On Tue, 30 Sep 2003, Robert Leland wrote:
<snip />
> I prefer Maven because it provides builds, testing, QA tools, and site
> generation in one tool.
> The repository of binaries makes building a distribution or maven
> enabled site as easy as typeing,
> 'maven' for new users.
> Changing the look/skin is straight forward, though as I say below I
> wouldn't invest alot of time
> tweaking it.
When you say one tool, you mean Maven plus any plugins that you need to do
what you want, like generate PDF. Since there is a Forrest plugin for
Maven, you still get all the "ease of use" of Maven.
> My main question to the items below is 'which of these features would we
> use for the struts site'
>
> >In short, Forrest offers these benefits over Maven's website generation:
> >
> > - Multiple output formats including PDF and HTML
> >
> >
> Maven has been doing this for a while now..
If you mean the PDF plugin, it seems from its page that all it does is
create one PDF of the whole site. Can you create PDF's of each page,
sections containing multiple pages? Its hard to evaluate the PDF plugin
as its documention is really lacking.
> > - SVG to PNG rendering
> > - Built for handling and aggregating multiple XML sources like RRS (soon
> >wiki and Docbook)
> >
> >
> Maven currently handles RRS, Docbook, and a few other formats, including
> the ability to take a
> preexisting framed html like JavaDoc and take it apart and assemble it
> again with a .maven wrapper.
> What's the wiki thing, and why do you think that would be usefull ?.
The Wiki support currently in Forrest, albeit under construction, supports
the parsing of Wiki text files for rendering. This allows the Wiki
information to be ran through the XML pipeline, most likely to end up as a
PDF. The ability to create PDF's out of wiki text would make wiki
information more useful, IMO.
> Could you give an example how multiple XML sources
> would be aggregated and used as a single source. How is this capability
> an advantage for
> the struts web site.
For example, currently, we have quite a few Struts extensions, example
applications, and related frameworks that I feel Struts could do a better
job of encouraging. Instead of requiring an extension developer to submit
a patch to bugzilla to change a description or add their project to the
page, why not have a page that aggregates extension project's RSS
announcing new releases into a news-type page. Giving extension projects
more exposure will generate more interest in finding ways to make Struts
better. Look what it did for Maven :)
> > - Power and features of Cocoon including charting, web services
> >integration, scripting support, etc.
> >
> >
> Charting is nice. What types of charting do we get for free or almost
> free that would help
> with our site. I believe Maven can provide charts about bugs reports,
While I mentioned these as nice features to have available, I wouldn't
mind have a page of graphs and statistics showing downloads, new bugs,
percentage of bugs as enhancements, number of bugs to go before the next
release, etc. In my experience, people love the concept of a "dashboard"
and what better way to get people more interested in fixing bugs?
> which I don't EVEN want to see ;-). How does web services/scripting fit
> into our needs?
The ability to embed small BSF-compatible scripts in the documentation
build process is a nice way to make something that would be more complex
using Ant/Jelly easy. Especially useful in something like the statistics I
mentioned earlier.
>
> >Further, deciding between Forrest and Maven isn't an either/or situation.
> >There exists a Forrest plugin for Maven and it would be easy to integrate
> >Maven's reports into a Forrest site build.
> >
> >
>
> I am assuming this plugin uses the maven xml doc files and generates
> forrest docs ?
No, just as the xdoc plugin generates html from xdocs, the Forrest plugin
would generate a site from Forrest docs. As hinted to earlier, it can
easily integrate into any generated documentation we'd like to keep from
Maven.
>
> >To me, the key feature of Forrest is the first one listed, multiple
> >outputs. This is especially useful for documentation as PDF is much
> >better than HTML for printing for the many users that like hard copies.
> >
> >
> Maven does this.
Again, I didn't see a way to do more than just generate one PDF for the
whole site, but of course, I could be wrong.
> >Finally, Forrest content is built to be presented in not only multiple
> >output formats, but multiple skins. To demonstrate this, I've quickly
> >redone the Struts site into Forrest format (which is very similiar to the
> >current format thanks to the xhtml work of late). I've only converted the
> >menu and the main page, which should be sufficient.
> >
> >
> We only need one look, though I don't like the default Maven look, but
> not enough bothering changing it.
> We may customize it but we won't be changing it dynamically.
I only included these links to show how output-independant Forrest was as
it was asked in an earlier discussion if Forrest docs had to look like the
Forrest website.
Forrest is built off of Cocoon, which IMO, is a mature, powerful, and
proven content publishing system. I admit I don't know that much about
Maven, so perhaps it can provide some the features I see unique to
Forrest. While I can't speak authoratively on Maven, I can say, in my
experience, Forrest is very easy to work with and very powerful. Since
Cocoon is under the hood, I know it is built on a mature foundation and
can be extended to just about anything we'd want to do with it.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by Robert Leland <rl...@apache.org>.
Don Brown wrote:
>I know the discussion on whether to use Forrest or Maven to generate the
>Struts website was a few weeks back, but unfortunately, at the time, I was
>too busy to participate. I'd like to lay out a case for Forrest, not to
>insist Struts uses it, but rather to make sure the decision is made with
>all the available information.
>
>
I prefer Maven because it provides builds, testing, QA tools, and site
generation in one tool.
The repository of binaries makes building a distribution or maven
enabled site as easy as typeing,
'maven' for new users.
Changing the look/skin is straight forward, though as I say below I
wouldn't invest alot of time
tweaking it.
My main question to the items below is 'which of these features would we
use for the struts site'
>In short, Forrest offers these benefits over Maven's website generation:
>
> - Multiple output formats including PDF and HTML
>
>
Maven has been doing this for a while now..
> - SVG to PNG rendering
> - Built for handling and aggregating multiple XML sources like RRS (soon
>wiki and Docbook)
>
>
Maven currently handles RRS, Docbook, and a few other formats, including
the ability to take a
preexisting framed html like JavaDoc and take it apart and assemble it
again with a .maven wrapper.
What's the wiki thing, and why do you think that would be usefull ?.
Could you give an example how multiple XML sources
would be aggregated and used as a single source. How is this capability
an advantage for
the struts web site.
> - Power and features of Cocoon including charting, web services
>integration, scripting support, etc.
>
>
Charting is nice. What types of charting do we get for free or almost
free that would help
with our site. I believe Maven can provide charts about bugs reports,
which I don't EVEN want to see ;-). How does web services/scripting fit
into our needs?
>Further, deciding between Forrest and Maven isn't an either/or situation.
>There exists a Forrest plugin for Maven and it would be easy to integrate
>Maven's reports into a Forrest site build.
>
>
I am assuming this plugin uses the maven xml doc files and generates
forrest docs ?
>To me, the key feature of Forrest is the first one listed, multiple
>outputs. This is especially useful for documentation as PDF is much
>better than HTML for printing for the many users that like hard copies.
>
>
Maven does this.
>Finally, Forrest content is built to be presented in not only multiple
>output formats, but multiple skins. To demonstrate this, I've quickly
>redone the Struts site into Forrest format (which is very similiar to the
>current format thanks to the xhtml work of late). I've only converted the
>menu and the main page, which should be sufficient.
>
>
We only need one look, though I don't like the default Maven look, but
not enough bothering changing it.
We may customize it but we won't be changing it dynamically.
>Please note, this examples are not polished and only serve to demonstrate
>the skinability of Forrest.
>
>Krysalis style: http://www.twdata.org/dakine/site/
>Avalon/Tigris style: http://www.twdata.org/dakine/site1/
>Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
>
>If we did decide to go with Forrest, I'm willing to convert the old site
>over and help handle any integration. I'm most definately not an expert
>at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
>easy.
>
>Don
>
>
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: The Forrest Option
Posted by David Graham <gr...@yahoo.com>.
I haven't used Forrest but Maven was pretty darn easy to get going. All I
had to do was download it and run "maven jar" or "maven site:generate".
It handled all of the dependencies by itself.
Assuming Forrest is as easy to use as Maven, I don't really care which we
use. I do prefer to maintain a site L&F that is fairly consistent with
other Jakarta projects so the Avalon style linked below looks good.
David
--- Don Brown <mr...@twdata.org> wrote:
> I know the discussion on whether to use Forrest or Maven to generate the
> Struts website was a few weeks back, but unfortunately, at the time, I
> was
> too busy to participate. I'd like to lay out a case for Forrest, not to
> insist Struts uses it, but rather to make sure the decision is made with
> all the available information.
>
> In short, Forrest offers these benefits over Maven's website generation:
>
> - Multiple output formats including PDF and HTML
> - SVG to PNG rendering
> - Built for handling and aggregating multiple XML sources like RRS
> (soon
> wiki and Docbook)
> - Power and features of Cocoon including charting, web services
> integration, scripting support, etc.
>
> Further, deciding between Forrest and Maven isn't an either/or
> situation.
> There exists a Forrest plugin for Maven and it would be easy to
> integrate
> Maven's reports into a Forrest site build.
>
> To me, the key feature of Forrest is the first one listed, multiple
> outputs. This is especially useful for documentation as PDF is much
> better than HTML for printing for the many users that like hard copies.
>
> Finally, Forrest content is built to be presented in not only multiple
> output formats, but multiple skins. To demonstrate this, I've quickly
> redone the Struts site into Forrest format (which is very similiar to
> the
> current format thanks to the xhtml work of late). I've only converted
> the
> menu and the main page, which should be sufficient.
>
> Please note, this examples are not polished and only serve to
> demonstrate
> the skinability of Forrest.
>
> Krysalis style: http://www.twdata.org/dakine/site/
> Avalon/Tigris style: http://www.twdata.org/dakine/site1/
> Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
>
> If we did decide to go with Forrest, I'm willing to convert the old site
> over and help handle any integration. I'm most definately not an expert
> at Forrest, but am familiar with Cocoon and thankfully, Forrest is
> pretty
> easy.
>
> Don
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org