Recommend a build tool for a large legacy Java project.

Question

I am the build manager on a large legacy Java project. It currently uses a combination of ant and nested shell scripts to do building, testing, and packaging. It is fragile and complex and old.

We'd like to replace it with a fresh set of scripts and are considering alternatives to ant. Maven 2 sounds interesting. We like the dependency management features, but the directory structure is to rigid for a legacy project and it seems overly difficult to do anything outside of their process.

Does anyone have a recommendation for this situation? Or experience in updating the build scripts of a legacy java project?

Answer 1

Can you give us more information about why ant isn't appropriate?

Once nice aspect of ant is that it sets a good pattern for use with cruise control, and if you've got a large legacy application that you're going to be fiddling with some form of continuous integration is perhaps a wise investment against breaking things.

Answer 2

I recently ported a legacy app using ant/custom script and ended up with something great using maven 2.

You can easily specifiy a custom directory scructure in the maven 2 pom.xml config file (while this is not the recommended way, is still good enough when going from ant to maven).

Also, maven support legacy ant task so you could combine the old legacy config and the nice features of maven.

Answer 3

I don't think you should use Maven unless your problem is with dependencies managaement and versions. If thats the only problem, use Apache Ivy. It's simpler, yet powerfull!

Ant should be able to do all the build job. The nested shell scripts are really needed? I would try to eliminate those.

Do you have a internal central repository? Do you use continuous integration? If not, you should consider. Take a look at hudson or cruise control

Answer 4

I would suggest to stick with Ant since the knowledge is already in-house.

The pragmatic steps I would take:

1. replace the custom shell scripts (if used for building and packaging) with Ant scripts
2. if you use 3rd party libraries, go with Apache Ivy
3. set up CruiseControl
4. clean up the test scripts

The main advantage is that, even if you don't go all the way to 4), you can still make your live more bearable with each step you take. If you go with Maven, the risk is that you'll not going to have something running for weeks.

Best of luck.

Answer 5

Ant not Maven

Answer 6

If you need to add scripting to your ant builds have a look at Gant which gives you Groovy scripting capability on top of your existing ant tasks.

Answer 7

I see, nobody has yet mentioned Buckminster.

Strictly speaking, it is not so much a build tool as it is a "resource materialization" tool. Resource materialization can be anything from fetching the sources into your file system or IDE of choice, to building the customer specific binary of your product.

It does component dependencies, handles flexible source resolution (you can map components to various source locations like cvs, svn, filesystem, eclipse workspace, maven repositories, etc.), can handle disparate component types (e.g. Eclipse project, Maven projects, etc.)

In the vein of the Eclipse projects, it is vastly extensible to handle almost any external tools, although since the project is quite young, You may find that you would have to write your own adapters to it in some less standardized use cases.

Compared to Maven (which is also a great build tool), it does not require as strict project structure and should fit much better your legacy project structure...