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.
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]
