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 :-(.
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]
