On Mon, 22 Mar 2004, Ted Husted wrote: > 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.
If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. > 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. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. > 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. Absolutely. And the number of repositories we have is entirely orthogonal to this. > 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. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) > 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. :) +1 > 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!) I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies of code, leading to the possibility of "why not mine?" kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. -- Martin Cooper > > -Ted. > > > > --------------------------------------------------------------------- > 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]
