"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > On Mon, 21 Jul 2003, Martin Cooper wrote: > > > > > Given that we have struts-legacy on its own release cycle, I think we need > > to decouple the struts-legacy build from the main Struts build. They were > > coupled shortly before the 1.1 final release, and that was a big pain when I > > was creating the release. I should be able to do 'ant clean dist' at the top > > level and point to an existing struts-legacy release, but I can't do that > > the way the builds are coupled right now. > > > > I could have just gone in and undone the coupling that was done (and I still > > could ;), but I'd like to understand why they are so tightly coupled before > > I do that. It seems not only unnecessary, but also highly undesirable, > > especially when struts-legacy is independently released. > > > > Decoupling this would probably be nice, but I don't think we're done if we > just fix that. I never thought I'd see a build environment more complex > than the one for Tomcat 4.1, but I think we've grown ourselves one :-(.
I agree that we're not done by just decoupling legacy from the rest. However, that's what I would recommend for 1.2 and the 1.1 branch. Beyond that, we've also talked about moving to a Maven based build. If we're going to make changes on the scale you suggest below, then I would far rather do that as part of a migration to Maven than do it independently, assuming we do decide to move to Maven. Otherwise, we run the risk of making life difficult for ourselves under Maven, and I, for one, don't relish the prospect of reorganising the code base more than once. ;-) While we're at it, this would also be a good time to reorganise the docs. If we move to Maven, then we should be able to take advantage of its site:generate and site:deploy targets, which would be very nice. Hmm. I'm beginning to think that perhaps 1.3 should be just an internal reorg release... -- Martin Cooper > > Isn't it time to start splitting chunks of this into inddependently > buildable subdirectories, and then create a top-level build.xml that only > does the appropriate things in the appropriate order? An example might be > to create a "core" subdirectory for the things we think would go into > struts-core.jar (informally, it's probably what we have now minus the tag > libraries but that's a detail). The directory structure might look like: > > core/ > build.xml Build for this chunk > src/java/ Java sources > dist/ Output directory for "dist" of this > target/ Output directory for "main" of this > > and we can start splitting things up one chunk at a time. The most > important concern is to minimize cross dependencies between the builds for > each subdirectory. The next consideration is that they should all default > up to a developer's own "build.properties" in the top-level directory, > instead of having a "build.properties" for each subdirectory. > > From this line of thinking, packaging releases becomes a function of > grabbing the "dist" output from the relevant top-level directories like > "core/dist". We could also dispense with "contrib" as an artificial > distinction, and just have all the individual components at the top level, > then decide what goes into a standard Struts release in each release plan. > > It wouldn't bother me to break the overall build for a while in order to > get this sorted out -- IMHO it's pretty broken already :-). But we might > also want to do a 1.2.0 first. Comments? > > > -- > > Martin Cooper > > Craig > > (jdk.version=1.4 solved one problem, but I'm still struggling to tweak all > the individual build.properties files to work in my environment) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
