On 3/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote: > > I can certainly buy into release consolidation along these four > paths. That > > being said, separating the source artifacts (and the binary jar files > that > > result from them) is still useful in terms of clearly articulating > > dependencies *within* a particular release. That becomes much more > > important as we offer finer grained jar files that are optional but > impose > > their own external dependencies. > > Certainly correct me if I'm wrong, but wouldn't this proposal more or > less do away with the idea of offering finer grained jar files? Except > for Tiles, which I know is being spun off on its own (I presume so the > same code base can support Struts, Shale and anything else?), are any of > the other "dwarfs" in the same kind of boat as Tiles? It sounds from > this proposal like they may not be?...
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). Craig
