Quoting Martin Cooper <[EMAIL PROTECTED]>: > 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. >
On the multi-repository projects I've worked on, we had a special repository just for integration tasks 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. :( :( :( > > 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. > Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. > > 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 > Yep. > > 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. > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
