On Wed, 29 Dec 2004 10:26:17 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Sat, 25 Dec 2004 00:31:24 -0800, Don Brown wrote: > > Well, technically, Tiles would be dependent on Struts-taglibs, not > > Struts core, but I agree, cloning the method is the easiest > > solution here. I mainly was using it as an opportunity to raise > > the larger issue of subprojects depending on other subprojects. > > Which, as mentioned elsewhere, lacking a dependency on the Core implies that > Tiles is not a good candidate for a Struts subproject anymore. A hard > dependence on the Core is what keeps us from becoming an umbrella project. > > I'd suggest that we continue to follow the "Commons" paradigm. Anything that > can be reused should be pushed up into it's own distribution. Everything we > distribute under struts.apache.org should be dependant on Core, and Core must > not be dependant on anything else we distribute. As we have been doing, > anything we can share, that is not dependant on Core, should be pushed down > into Commons, or out into its own project (e.g., Tiles). > > Anything that Core needs, that is itself dependant on Core, should be part of > Core (e.g., TestCase). > > > On Mon, 27 Dec 2004 14:17:27 -0800, Don Brown wrote: > > Darn. I suppose we could make an examples subproject, but the > > original reason to have subprojects is the ability for them to have > > a separate release cycle, which wouldn't really apply to examples. > > On the other hand, it wouldn't be good to have code in Core that > > depends on subprojects. > > As to "examples", are we not moving the web applications into an Apps > subproject? >
Ah yes, we did say we were going to do this. I might have a go at that today, since we'll need to pull it out to get 'ant clean dist' in core to build again. > I'd suggest getting a Core milestone building first, so that we have a JAR > that can be imported by other nascent subprojects, like Taglibs, Extras, and > Apps. > Yep, that's my immediate goal. If I can rationalise the source tree structure, I can get the first part of the build process in place as well. > I believe we are trying to follow a "divide-and-conquer" strategy. > Subprojects should depend on milestone releases of other subprojects. So, > we'd want to get a milestone of one thing out first, and then the other. > Well, I'd like to get the various pieces building before we start thinking about milestones, so that we can have a nightly build that includes the various pieces, as we had before. Right now, the nightlies are broken. Also, bear in mind that part of the testing for the taglibs happens through the exercise-taglibs sample app, so it would be good to have that working before we start distributing taglibs milestones. > Obviously, everything is not going to work perfectly together the first time. > We'd have to roll Core and Taglibs before making any Apps releases, and the > Apps are going to expose oversights in the 1.0.0 milestones of Core and > Taglibs. But we can make fixes and bring out new milestones of each until a > distribution falls into place. > > We might focus on rolling a Core milestone first. Once that is building, we > can bring out a Taglibs milestone which is dependant on that. Then, Apps > milestones that are dependant on Core and Taglibs. Rinse and repeat. > Core/Taglibs/Extras/Apps. Later, Core/Taglibs/Extras/BSF/Flow/Apps. And so > forth. > Um, what's 'Extras'? I don't recall one of those, and am not sure what would be in it. > If we have trouble finding a sequence in which to build the subprojects, then > a subproject might not be cohesive, and we might have to rethink the > divisions. But, we should follow the code, and let the code tell us what > belongs together. > Yep. And if what the code tells us doesn't make sense, then it's time to refactor. > One thing that would help make this work is a repository system. Either > Maven's or our own. The Core JAR should build to a place-certain, and then > the other subproject builds should be able to find that JAR and use it in > their own builds. For example, each subproject can drop a JAR into a lib > folder under the local copy of the Build project. > Yep, the new build I have in the wings will take care of that. > If a new release of Taglibs breaks Apps, so be it. The production release of > Apps would still work with the prior production release of Taglibs. Bring out > Taglibs, and then fix Apps. > As I mentioned above, some of the testing of Taglibs happens though the use of one of the Apps, so I'd prefer to see at least that app work before bringing out Taglibs. > When we have a set of production subproject releases that all play well > together, we could roll a new distribution. But, we would not have to roll a > new distribution every time a subproject brought out a new release. Only when > the pieces fit together. > If we make it easy enough for people to grab the pieces they need, we might not need the bundle eventually. But people will expect it in the near term, so we should provide it. > The one thing I don't ever want to get into again is another 1.1 death march, > where we are trying to fix several things at once, and have to have > everything perfect before we could release anything. Not releasing is very, > very bad, since most teams can't use what we don't release. Given our limited > resources, and the need to get things "out-there", we have to find a way to > do things hand-over-hand. > Yep. I expect we'll learn how to do that in the process of breaking things up, as we are. In fact, I suspect we'll learn things we never knew about the source code, too. ;-) -- 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]
