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? 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. 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. 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. 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. 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. 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. 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. 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. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
