File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Ant, Maven and Other Build Tools and the fly likes large project (GUI, ejb, web stuff) - more than one ant file? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "large project (GUI, ejb, web stuff) - more than one ant file?" Watch "large project (GUI, ejb, web stuff) - more than one ant file?" New topic

large project (GUI, ejb, web stuff) - more than one ant file?

paul wheaton

Joined: Dec 14, 1998
Posts: 20972

I'm working on a large project that has lots of sources of information and lots of destinations. We have EJB's, servlets, JSP's, a swing client, JMS code, etc. Some of this stuff goes into an application, some has be be run through an EJB processor and some gets stuffed into a WAR file (and some doesn't).
Would one ant file be wise, or several?

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Greg Charles

Joined: Oct 01, 2001
Posts: 2968

I'm working on a large project right now, and I wrote multiple Ant files for the build. As an approach, it has some pros and cons. I can easily separate out targets to build one jar or set of jars, when that's what I want to do. On the other hand, when I want to do a full build (which is usually in my case), I run through a lot of extra dependency checking and have to duplicate a fair amount of code. Also, you can't make targets depend on targets from other build files. Overall, I still think it's worth it. My build.xml would be huge and terribly complicated if I didn't break the build down. I have a properties file that reduces the duplicate code. I just have to load it at the top of each build file. Then, if I happen to change the directory structure, or compile flags, etc., I just have to change one place, in the properties file.
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
I've worked with Ant on a lot of similarly complicated projects, and I've come to use one build script pattern more and more.
I think of this as "organize by operation". For example, in one of my current projects I need some of the compiled class files to be placed in a jar file in WEB-INF/lib and some to be placed directly in WEB-INF/classes. It's tempting to just assume that all java source code goes in one directory, and pick it apart some other way (pattern matching on file names or whatever) but this invariably leads to problems. So I have two source code directories (in this case "lib" for the ones destined for the jar, and "loadable" for the others). Similarly, XML files destined for direct inclusion in the war file go in one directory, and ones aimed at XSLT processing to produce web pages go somewhere else.
Once I have split the project up into operation groups like this, I put together the ant stuff. A (very abbreviated!) example directory tree will probably make this a bit clearer:

If I start ant as follows:

it loads build.xml and runs an "init" target which loads properties from project.prp (web app name, userid/password for testing etc.) for the application, then calls out to "../../config.xml" which checks for the existence of the various "operation" directories, setting properties as appropriate, then runs the dependencies of the named target. General purpose dependent tasks call out to other ../../*.xml build files, application specific-tasks are coded in line.
This is the closest I have come to refactoring of Ant build scripts. Theoretically, the bulk of the project-specific build file could be autogenerated based on project properties, directory and file existence etc. At the moment though, I'm still in cut-n-paste land. It's mainly just a bunch of

which is hardly onerous, though.
Does any of that help ?

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
I agree. Here's the link:
subject: large project (GUI, ejb, web stuff) - more than one ant file?
It's not a secret anymore!