This is as much a build environment question as an Ant question, but here goes. I'm on a team that is building an enterprise application - it contains ejb's, web apps, and a couple of stand-alone client apps. They're all bundled into an ear file for deployment. The trouble is in the build environment. We have the following directories: src/ - all source files lib/ - jars to use for compile and deployment etc/ - config files ... build.xml We use one build.xml (for now) to build everything, with targets that can build each individual application, or the whole thing. It's getting unmanageable, and I'm considering a different structure: /ejb /src/ /lib/ /etc/ /webapp1 /src/ /lib/ /etc/ /webapp2 /src/ /lib/ /etc/ /clientapp1 /src/ /lib/ /etc/ Each app will have its own build.xml, and then there will be one main build.xml at the project root that can call the other build files. Any thoughts on this? I'd like to get feedback from people who are managing big projects. Chris
This is how companies I have been at in the past have done it. A root project with calls deeper into the source tree. One other approach along this line is to actually put all of the xml into one location and then using entity includes,build the deeper xml files. This can be nice becuase all of your build 'code' can be found quickly and easily in one place but .. the deeper build files are a bit less readable.
I'm in the process of building a big J2EE app, consisting of session beans, Struts, and other layers such as a common tree of source that is common to all tiers. I've crafted it such that the src directory contains "common", "ejb", and "web" subdirectories, each with its own package hierarchy. There is one build file that builds all pieces of it and bundles it into a full EAR. Until we need the pieces broken out into pieces used by other apps it is simplest to keep it all together. The advice I have is to keep the trees easily separated, and don't use patternsets (includes/excludes) stuff to isolate out pieces of a source tree into components - let the directory structure mirror the components that need to be built.
Well, I just finished putting a lot of includes/excludes stuff in our master script. I know how I'll be spending my afternoon.
Joined: Jun 11, 2002
An advantage to keeping your directory trees separated, for example in the app I'm building right now, is that it allows us to pull the "common" tree out and move it up another level so that new projects can use it when/if it comes to that. I feel for you having to refactor your build file, but in the long run it will be well worth it for future maintenance and for new developers - they simply create new source code and don't have to worry about having to change the build file patterns to pick things up, for example.
Joined: Apr 03, 2002
I completely agree; everything is obvious on the other side of it. Now, if I can just get everyone to stop coding for a minute so I can move their files around...