In the last post, we discussed the importance of a clean target. Is it your first time? Have a look at the index page.
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.
Related posts:
- A way to cool dependency Hell? How to break a deploy: Take one codebase. Sieve in...
- Giternal Debian package Giternal is a handy tool for managing git submodules. Give...
- What is a Maven POM? Why I am asking about Maven POMs? I do...
- Build Refactoring Build Refactoring: Refactoring is a nice term for making something...
Related posts brought to you by Yet Another Related Posts Plugin.
{ 1 trackback }
{ 0 comments… add one now }