[EMAIL PROTECTED] wrote:
> Do you mean check in the generated versions of the 1.0 docs, so that they
> can be included in the struts-documentation.war and therefore land up on the
> web site? If so, +1.
Done. For lack of a better idea, I setup a "legacy" folder with a
api=1.0 subfolder, and amended build-webapps.xml to copy it over to the
target/documentation folder.
Haven't tried to make any of this "live" yet though.
> Currently, there are only two items in the menu that are not 1.1 related
> (User Guide and 1.0 Release Notes). Are you proposing separating only the
> documentation part of the menu into two sections, one for 1.0 and one for
> 1.1, or the whole menu?
What I'm proposing is that we segregrate the "Current Development"
items, and maintain the 1.0 items as the defaults. I've checked-in a new
project.xml that runs like this:
About Struts
+ Home
+ User Guide
+ Resources
+ Who We Are
+ Mailing List
+ Bug Database
Getting Started
+ Installation
+ Release Notes
+ Javadoc
Java Developer Guides
+ Digester
+ Utilities
Tab Library Guides
+ Bean Tags
+ HTML Tags
+ Logic Tags
+ Template Tags
Tag Library Reference
+ Bean Tags
+ Logic Tags
+ Template Tags
Current Development
+ Release Notes (nightly)
+ Javadoc (nightly)
+ Workflow Proposal
+ TODO List
> If the goal is to have a more complete set of pages for both 1.0 and 1.1 on
> the web site, then perhaps we should think about having the 1.1 (or latest,
> which is currently 1.1) pages at the site entry point, and have a link to
> the latest-stable-release "sub-site", which would look very similar but
> contain only 1.0 data.
I'd suggest the reverse. There's still a lot to be done with 1.1, and we
shouldd promote 1.0 as the default entry point. If 1.1 is the
entry-point, it sends the message that people should start using that
version, when I don't believe they should. I personally don't feel that
we've even defined what will be in 1.1. We've collected a number of
suggestions, but that doesn't feel like a feature set to me.
> I'm not clear on what you mean by "conform", since I can see two
> alternatives. Option 1 would be to clone your site into Struts Resources, so
> that they both contain the same material. Option 2 would be to take your
> page, turn it into the Struts Resources page, and "reset" your page to
> simply refer to the Struts page. Subsequent additions might then be made to
> your page, which would later be merged into the Struts page.
>
> Of these, I would prefer option 2, because (a) resource information would
> not be duplicated, and (b) it would be easier for people to identify what is
> unique to your site (and therefore new).
It's difficult for me to keep the Struts pages updated on a
rapid-development basis, so I went with option 1 for now.
> > + Create standalone Digester and Bean-Utils Developers guide with
> > Struts-specific information, and then link to the Commons for general
> > information.
>
> Not sure about this. Can you elaborate on the kind of Struts-specific
> information you have in mind? Also, the individual Commons projects do not
> seem to publish any documentation on the web site, so there are no developer
> guides available as there were prior to those components moving from Struts
> to Commons. I would definitely be +1 on having documentation available on
> the Commons site.
For the time being, I would like to at least bring back our original
developer's guide, now that we have the 1.0 API back on board. The
Commons is still in a shake-down period, and I want to be sure that our
developers at least have the 1.0 documentation handy. Of course, I would
plan on amdend this with a statement about it being deprecated and
moved. Ditto for the Bean-Utils.
-- Ted Husted.
