ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: "Elements of Ant Style": ant files separation
Date Tue, 05 Nov 2002 01:39:57 GMT
My recommendation is

-break your project into sub projects at sensible places, each with their
own deliverable (jar, ear, docs) that can be tested

-have a build file for each sub project
-have a master build file for the whole thing, using <ant> to call down
-use XML includes to pull in common declarations across all build files.
-have helper build files for common tasks, these files are like subroutines
that take parameters as properties and do things for the big files. e.g.
javadoc, jmxdoclet,
-use junit report to build a big fancy report of the entire test run. people
love that.

----- Original Message -----
From: "Emerson Cargnin - SICREDI Servi├žos" <>
To: "Ant Users List" <>
Sent: Monday, November 04, 2002 8:47 AM
Subject: Re: "Elements of Ant Style": ant files separation

I'd like to make question about the architecture of ant files:

I have a big financial system, with a lot of modules, so we planned to
separate the big build file into smaller build files, what should be the
preffered way
- creating one build file for each module
- creating one build file for each layer, say, web, ejb, eyc...

I prefer the first approache, but the people here seems to preffer the last.

And if i use the first, how to keep what not  change in a single build
file and let each module keep just what changes? I know i can have file to separate properties that change, but it doesn't
  extend to different targets....

I saw the fisrt approache at jboss project.

One problem with the first approache is when you use CMP entities that
have CMR's, becouse it need to be deployed in a single ejb-jar.xml

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message