On 3/20/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > Java Web Parts - > http://javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
