struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Date Mon, 20 Mar 2006 19:16:23 GMT
On 3/20/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
> Craig McClanahan wrote:
> > For Shale, at least, I would *not* advocate eliminating separate JAR files.
> > There are optional features of Shale that themselves have their own
> > dependencies, and it would be a burden on all Shale users if everything was
> > combined into one JAR file.  As Ted mentioned earlier in some thread, this
> > is a lesson that we in the Struts community can learn from what Spring is
> > doing.
> >
> > Two use cases in the Shale world:
> >
> > * Shale Remoting -- a completely standalone JAR file that does not depend on
> >   anything else in Shale, but is useful for component authors and app
> > developers
> >   doing AJAX style development.  40k and zero dependencies, versus 140k
> >   (for shale-core.jar) and a bunch of dependencies.
> >
> > * Tiger Extensions -- optional layer on top of Shale that utilizes JDK
> > 1.5annotations
> >   to reduce or eliminate configuration files.  Including this stuff in a
> > core Shale
> >   JAR file would require *all* users to be based on JDK 1.5.
> >
> > In the Struts 1.x world, the same kind of argument applies to
> > struts-el.jar(only needed if you are on a < JSP
> > 2.0 platform) and struts-faces.jar (only needed if you are using JSF
> > components in a Struts based application).
>
> That all makes perfect sense, thanks Craig.
>
> You know, I was looking at the Struts front page a few minutes ago,
> specifically the "Extensions", which are the seven dwarfs IIRC.  The one
> that sticks out for me as a "problem", if that's the right word, is the
> JSP Taglib.

there have been VelocityStruts users eager for the Struts tags to be
separated from the core for a long time.  there's plenty of people
using Struts without the tags.

> I think it's fair to say that the majority of Struts developers consider
> the Struts tags to be intrinsically part of the Struts Action Framework
> (SAF).  Except for me who rarely uses them! :)
>
> The analogy I would use us the component kit you use in a JSF app...
> *can* you build a JSF app with no component kit at all?  I would guess
> yes... but how many people *would* ever do that?  I would guess very
> few. I think the same is true of the Struts tags.
>
> I think everything else, Tiles, Flow, EL, etc., really do seem to me to
> be true "extensions", and as such it makes sense for them to develop on
> their own, be packaged on their own, and be downloaded separately as
> needed.  My only concern there is simply to document well what
> version(s) of a given extension can be used with a given version of SAF.
>   I think this information should always be front and center and easy to
> find quickly.
>
> But, the JSP Taglib, that one I think really does make more sense to go
> along with the core itself.  I'm not saying it can't be its own JAR...
> that's just a matter of the final build artifact.  I'd probably opt to
> include it in the Struts JAR, but that's really a minor point IMO.  What
> is more important is that I think the taglib should share the same
> version number, release cycle, etc., as the core, and in fact should
> just simply BE part of the core.
>
> I guess I'm saying I would propose amending Don's proposal to only apply
> to the Struts taglibs :)
>
> > Craig
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message