date:20031001

Re: The Forrest Option

2003-10-01 Thread Don Brown

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

2003-10-01 Thread Ted Husted

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]

Raising feature requests and fix suggestions - What's the accepted way.

2003-10-01 Thread Richard Tomlinson

Hi,

I've got a number of issues that I'd like to raise regarding feature requests with 
suggested fixes.  Can someone inform me of the best way to go about this?   I'd like 
to know what the process is to suggesting, raising and fixing features and problems so 
that they can be destined for the next release.

I'd like to initially tackle the following issues:

o  html:errors tag - Add the ability to specify the maximum number of errors to 
display rather than displaying all available errors.

o  html:link - Improve the way it handles multi-module support.  My previous message 
regading module support was unanswered.

o  Adding ActionMessages/ActionErrors from a specified resource bundle - I saw a patch 
for this that unfortunately didnt address the issue correctly (Bug 7892)

o  The addition of a ReloadableActionServlet to be used for development purposes.  I 
take note of the comments seen before regarding reloading and sync'ing requests so it 
would be useful for ONLY development purposes.  The gain in productivity is 
substantial when its possible to reload without restarting the container and a 
reloadable ActionServlet should be included in the distribution.   From a simple 
implementation it appears that there are clean-up problems needing to be addressed 
with the tiles factory and request processors being left in invalid states but still 
present in the ServletContext.   I'm also interested in support of real-time changes 
to modules without re-loading config to facilitate the use of CMS products in a large 
production environment.

Comments please.

Regards
Richard Tomlinson

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Raising feature requests and fix suggestions - What's the accepted way.

2003-10-01 Thread Ted Husted

To discuss whether a feature might be a good idea, you can post here.
Though, it can take several days before everyone weighs in. We're all
volunteers with real jobs. Many of us can only work on Struts on the
weekends.

To raise and fix issues, you can post tickets to Bugzilla. This is where
patches should go, so they don't get lost. If you have an alternate
patch, you can append that to the same ticket.

If you strongly believe in an issue, you might have to lobby for it.
This is often the case in open source. On another project, I had to make
several followups over a two-week period before getting a three line
patch committed. It's just the way things work on volunteer projects.

Bugzilla, the DEV list, and CVS are the only media that the committers
use to develop Struts. Both Bugzilla and CVS are programmed to post
changes to the DEV list, so everything that happens is reflected here.

38 matches

Mail list logo