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" <[EMAIL PROTECTED]> To: "Ant Users List" <[EMAIL PROTECTED]> 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 build.properties 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: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
