----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Monday, January 21, 2002 3:52 AM Subject: Re: Struts Next
> Right now, we're exploding the struts-documentation WAR to create the > Web site. Having worked with the Anakia way (a la commons and site2) a little bit now, I have to say that I like that web site update process much better than our exploding war file. It's simpler and quicker. I wonder what other folks think about migrating to this process at some point? This would also release us from the one-to-one mapping we currently have between what's bundled with the release (i.e. struts-documentation.war) and what's on the public web site. (See below.) > We've been trying to keep the latest release front-and-center, mainly > because we seem to have a large base of professional teams that cannot > use unreleased software. And I think we should continue to do that. Otherwise, we'll go back to the endless questions on struts-user about why something documented on the web site (for the nightly build) doesn't work (because the user is using the released build). > How about if we start to carry a copy of the documentation for the > latest formal release -AND- the nighly build on the Website. The nightly > build could be on top, but have an absolute link to the documentation > for the prior release on the Website > (jakarta.apache.org/struts/1.0.1/...). This way people who want to scope > the current release first (since that's the one they would have to > propose today), can get easy access to that, but we still have the > latest and greatest out-front. I'm definitely +1 on carrying full documentation for both the latest "official" release and the nightly build on the web site. I'm not so sure about having the nightly build docs on top (see comments above), but I think if we can make it sufficiently obvious as to what's what, it shouldn't matter too much. To make it "sufficiently obvious", we could consider ideas such as graphics to distinguish the two, or (probably more workable) making neither available on the top level page, but having separate links to the comprehensive docs for each version. One other point here, related to my earlier comments about the one-to-one mapping. While the web site should contain docs for both current release and nightly versions, I think it would be a good idea for the struts-documentation.war web app to contain *only* the docs for that version. I don't see a need for that part of the binary download to contain docs for multiple versions, and I suspect that simplifying the docs web app will also help users to understand what exactly they have downloaded. Putting this together with the use of Anakia to generate the web site content could simplify things considerably, since we should then be able to use CVS tags to manage our docs and our web site more easily. > We also need to be scrupulous about marking new code and documentation > with @since statements. I've started to fix these as I find them, and > will continue to do so. Although perhaps less useful if we have separate complete docs for release and nightly, it would also be useful to have the taglib docs indicate when tags (and even individual attributes) were first introduced. > I've got a start on the release notes, and then will look updating the > User Guide from those. > > I've also started a News and Status page in the nightly build, and will > continue to work on that. This will supply the material for the new > Jakarta newsletter. Sounds good! -- Martin Cooper > > -Ted. > > > Ted Husted wrote: > > > > Craig R. McClanahan" wrote: > > > > p.s. I saw the other thread on the multi-app support you checked in. Good > > > > work! (Do you sleep? :) I should check it out soon. > > > > > > I've got one more useful new goody on my workbench - an ActionForm > > > implementation that uses the new DynaBean APIs in the Commons version of > > > BeanUtils that let you define form beans without having to write all the > > > properties in individual bean classes. > > > > > > After that, maybe I can get some sleep. :-) > > > > Well, I'm fairly well rested :), and cant block out some time this > > weekend to start catching up the User Guide with the latest changes, so > > we will be ready to go to Release Candidate soonest. Also need to put in > > more Since 1.1 markers. Seems that we missed a few :( > > > > The MultiApp support coupled with DynaBeans will be a giant leap > > forward. Fighting over the struts-config and twiddling with ActionForms > > is the two leading issues when I talk to teams that are considering > > Struts, or using in on their first project. Of course, these same teams > > can't use "unreleased" software, so I'm eager to move this along any way > > I can. (Including doing the Release Manager thing, if that helps.) > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > > -- Building Java web applications with Struts. > > -- Tel +1 585 737-3463. > > -- Web http://www.husted.com/struts/ > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Building Java web applications with Struts. > -- Tel +1 585 737-3463. > -- Web http://www.husted.com/struts/ > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
