James Turner wrote:
From the user's POV, if its in the primary download, then it's part of the core distribution.I would suggest that struts-el be packaged as a separate download from the Struts 1.1 core, on the grounds that...I can take the alternate view, which is that because struts-el is in the
contrib directory, it implicitly has lower standards for release quality
that the core distro.
And, AFIAK, Apache "release quality" is binary. It is or it isn't. There aren't any shades of grey in the moniker "Release".
-Ted.
I also feel that, given that the changes made in
the repository since 1.1b3 have all been bug fixes (with I think 1 or 2 extremely minor exceptions), recycling to another beta is just a good way to throw another couple of weeks onto the release cycle.I think that the idea of declaring an RC1 is more a statement of intent to deliver a finished product based substantially on what we have now in a very short timeframe, we already strongly suspect an RC2 would have to be delivered in mid-Feb to catch up bug fixes from RC1 once people start to examine the release seriously.Regardless of what we do in this instance, could we clarify as aguideline1) Whether Beta to Release candidate votes are on corresponding CVStag. Given that there have been bug fixes since 1.1b3, I'd say we'd want to base on nightly build.2) Whether we want to go from the nightly build to a RC without an intervening beta.
I don't see why not, we don't do betas between release candidates (i.e.,
we go directly from RC1 to RC2), so we should be able to go from 1.1b3
to RC1, especially as it's been almost entirely bug-fixes.
I'll recycle the vote one last time to make things clear, and we'll see
where the vote lie.
James Turner
Owner & Manager, Black Bear Software, LLC
[EMAIL PROTECTED]
Author: MySQL & JSP Web Applications: Data Driven Programming Using Tomcat and MySQL
ISBN 0672323095; SAMS, 2002
Co-Author: Struts Kick Start
ISBN 0672324725; SAMS, 2002
Forthcoming:
Java Server Faces Kick Start SAMS, Fall 2003
-----Original Message-----
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.
* 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.
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.
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 :(
-Ted.
David M. Karr wrote:
David> The only added attribute was "cdata" that"David" == David M Karr <[EMAIL PROTECTED]> writes:"David" == David Graham <[EMAIL PROTECTED]> writes:defaults to true on the javascriptDavid> tag. I'd like to see this included in therelease because it rounds out theDavid> xhtml functionality.
David> We have yet to hear back from Martin if he isvetoing this change. If he does,David> then I'll remove the attribute and always put acdata section around theDavid> javascript in xhtml mode. Obviously, I andother xhtml users would beDavid> dissapointed.
David> And on that note, remember that we need to makesure that any attribute changesDavid> in the base library get into Struts-EL. Therewere some attribute changes madeDavid> right before the 1.1b3 tagging, which was duringa five day period when myDavid> house was without power for 79 hours, so Iwasn't able to get the associatedDavid> Struts-EL changes in until after 1.1b3 wastagged. I don't think that is aDavid> real problem, but it will be a real problem ifsomething like this happens forDavid> the real release.really voting on
I'm not sure this matters at this point, but if we're
taking the 1.1b3 tag as rc1, I guess I'd -1 that, based onmy previous
comment. If we used 1.1b3, The "html:link" tag will havean "action"
attribute, but the "html-el:link" tag will not.elements with
Is there an easy way to get the diffs or comments of all
commits since the 1.1b3 tagging?
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <mailto:struts-dev-> [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]>
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>