FWIW I'm with Martin on this. I don't understand the advantage having separate repositories will give us. Even under one top lever repository directory, we can organize the Struts product(s) however we like.
The only advantage I can see in having separate repositories would be to make it easier to grant different groups of committers access to different areas. But that's not what we want to do anyway. Another reason NOT to split into several top level directories is that it adds more clutter to the already busy Apache repository. IMHO fewer top level directories makes it easier for people to find what they need. If there's a compelling reason to split into several top-level repository directories that hasn't been stated (or I've missed), please let me know, otherwise I'd prefer to keep as few as possible. But it's not a life or death issue either way :-) Steve > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: March 22, 2004 11:50 PM > To: Craig R. McClanahan > Cc: Struts Developers List > Subject: Re: Making Struts Build Easier (Re: "coming out" for JSF + > Struts, was: Struts JSR?) > > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
