On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: > While it's great to break out things into separate "modules" - I'd > love to be able to get struts.jar w/ everything in it - including > EL and tags. I can live with all the commons-* JARs (even if it is > annoying), but in general - the less JARs, the better. It just > simplifies things for the developer. > > I don't care how things are partitioned in CVS, as long as > everything builds with one checkout and one command.
If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a "general availability" ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to "everything right" in order to one little feature into a formal release. If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts "opt" subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions "the nod", we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up "hiding our light under a bushel". Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code "rationalized". (First things first!) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
