Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
--- Robert Leland [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 8:51 AM Subject: Re: The Forrest Option --- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
--- Don Brown [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build improvements (was Re: The Forrest Option)
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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build improvements (was Re: The Forrest Option)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build improvements (was Re: The Forrest Option)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
David Graham wrote: --- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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 LF that is fairly consistent with other Jakarta projects so the Avalon style linked below looks good. David --- Don Brown [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
