On Mon, 22 Mar 2004, Craig R. McClanahan wrote: > 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.
So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? > > > 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]
