struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Date Sun, 19 Jan 2003 22:46:57 GMT


On Sun, 19 Jan 2003, Ted Husted wrote:

> Date: Sun, 19 Jan 2003 06:42:26 -0500
> From: Ted Husted <husted@apache.org>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: Struts Developers List <struts-dev@jakarta.apache.org>
> 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:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message