> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 19, 2003 6:42 AM
> To: Struts Developers List
> Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
> 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. 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 a
guideline
>1) Whether Beta to Release candidate votes are on corresponding CVS
tag.
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" == David M Karr <[EMAIL PROTECTED]> writes:
> >>>>>
> >
> >>>>>>"David" == David Graham <[EMAIL PROTECTED]> writes:
> >>>>>
> > David> The only added attribute was "cdata" that
> defaults to true on the javascript
> > David> tag. I'd like to see this included in the
> release because it rounds out the
> > David> xhtml functionality.
> >
> > David> We have yet to hear back from Martin if he is
> vetoing this change. If he does,
> > David> then I'll remove the attribute and always put a
> cdata section around the
> > David> javascript in xhtml mode. Obviously, I and
> other xhtml users would be
> > David> dissapointed.
> >
> > David> And on that note, remember that we need to make
> sure that any attribute changes
> > David> in the base library get into Struts-EL. There
> were some attribute changes made
> > David> right before the 1.1b3 tagging, which was during
> a five day period when my
> > David> house was without power for 79 hours, so I
> wasn't able to get the associated
> > David> Struts-EL changes in until after 1.1b3 was
> tagged. I don't think that is a
> > David> real problem, but it will be a real problem if
> something like this happens for
> > David> the real release.
> >
> > I'm not sure this matters at this point, but if we're
> really voting on
> > taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on
> my previous
> > comment. If we used 1.1b3, The "html:link" tag will have
> an "action"
> > attribute, but the "html-el:link" tag will not.
> >
> > Is there an easy way to get the diffs or comments of all
> elements with
> > 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]>
