On Sun, 19 Jan 2003, Ted Husted wrote:
> Date: Sun, 19 Jan 2003 06:42:26 -0500 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 > > It was my original understanding that Struts-el lived in the contrib > folder, as Craig mentioned he would do with Struts-JSF. One advantage of > this is that Struts-el (and Struts-JSF) could have their own release cycle. > > In general, I would to see us position Struts as a model and view > agnostic Controller. As alternatives like JSTL, JSF, XML/XLST, become > more common place, we will want to move the Struts taglibs out of the > core distribution and into an optional distribution. This implies that, > in general, we should be trying to decouple taglib implementations 0from > the main distribution. > This approach makes sense to me -- and could pretty easily be adddressed i the roadmap item for 1.2 I just added on reorganizing the build process. > I would suggest that struts-el be packaged as a separate download from > the Struts 1.1 core, on the grounds that > > * As I understand it, struts-el requires the JSTL which in turn requires > servlet 2.3. Our technical minimum requirements for Struts 1.1 are still > servlet 2.2. > > * Packaging struts-el separately conincides with the long-term view for > the product. > Does it make sense to (perhaps also) have a "contrib" distribution that contains the "latest released version of all the contrib packages at a given point in time"? I'm going to be advocating for something similar for commons - and even created a package (commons-combo) that lets you combine your favorite released versions of all of them into a single JAR, with consolidated JavaDocs. > In general, I'd like to suggest that stop thinking of Struts as a "one > site fits all" distribution, and starting thinking of it as a core, > central controller that people can use with other products, like > Struts-JSF, Struts-el, or the original Struts JSP taglib. > If you're also subscribed to STRUTS-USER, you've probably seen the recent uptick in interest around adding XML/web service support into Struts, and that would fit quite well with this philosophy. My only doubt would be on the timing ... doing this sort of thing now seems like just one more cause for delay to an audience that is getting increasingly impatient. Can we do the reorg changes in 1.2 / 2.0 instead? > As it stands, struts-el has been documented as a contribution and does > not appear with the other developer guides (mea culpa). Making it a > standalone distribution is just a matter of changing the build script. > This would then allow David to make a new release of struts-el without > forcing a new release of the core framework. > > So, I will have to join David Karr in casting a negative vote as to > promoting the beta to a release candidate as it is now built, on the > grounds that struts-el should be distributed separately. > > Of course, since this is a majority vote situation, > > http://jakarta.apache.org/site/decisions.html > > these -1s will not prevent a release, unless other committers change > their vote. (My chance to veto the idea unilaterally was when the > build.xml was first changed, but that boat has sailed :( > It's clearly not a good idea to formally label 1.1b3 as a release candidate if we're not in consensus. However, rather than continue discussing it, that energy would be better spent resolving the remaining bug reports :-). > -Ted. > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
