Today, I want to talk about managing dependencies with Ant. What does that mean? In this case, it means managing the dependencies on code within your project: dependencies in code, third party libraries, etc. I want to cover dependencies between other projects in another post.
The advice is to start from the very bottom up. You have a bunch of common utility files? Compile them up in one target. And make sure that target outputs one thing and one thing only: a jar file called common.jar. Now, that file isn’t going to be your enterprise application on it’s own, so do the same to the code that references the classes inside common.jar. Make sure that each one of those outputs a single artifact, and that each one of them depends on the target for common.jar. Now, you probably have a web application or two that depends on a jar file of business code, which depends on a bunch of common files that nobody can decide where to put – common.jar.
What if there’s a separate project for the front-end project, vs. the back-end? You still want to package up the code as jar files for consumption by the other project. But for the love of God try to resist doing that. Most projects really only have one product that they make. To split them up into different, smaller projects adds a whole world of complexity.
What we just did was stop anybody from breaking the build by making the back-end code depend on the front-end code. Which is quite easy to do when your IDE allows you to do that in a few keystrokes.
This technique will create some good karma for your project, as long as you follow the sane practice of making every developer run the Ant build before they check in. For me, this is critical. Nice one, Eric.