By
"-use XML includes to pull in common declarations across all build files."
do you mean using an external entity?
<!DOCTYPE myproject [
<!ENTITY importedAntFile SYSTEM '../../common/build.xml>
]>
<project ...>
&importedAntFile; <!-- imported elements imported here -->
<target ...>
</target>
</project>
If so... that is so cool. The first time I saw this was with the Sun Web
Services SDK.
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 04, 2002 6:40 PM
To: Ant Users List
Subject: Re: "Elements of Ant Style": ant files separation
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
