This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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?
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.
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 ?