views:

1451

answers:

9

From my small amount of experience, I've only used Ant as a build tool. Are there any other projects which are better, and why?

+13  A: 

Maven

It is much better than ant because for most common tasks you don't have to write a complicated build.xml, maven has very good defaults and it's all convention over configuration.

It has also a big central repository of libraries and it's very easy to configure it to, like, "use latest stable commons-whatever". Maven will then download the latest stable version for you (no more checking in jars into VCS) and if a new upstream stable version is released, it will download it as well. Of course, it's just as easy to lock it to some specific version should you need that.

It is also well integrated both with Netbeans and Eclipse (m2eclipse plugin) so the IDE honors whatever settings (including dependencies) you declare in the pom.xml file.

There are also some downsides to maven: some plugins are rather poorly documented, integration with both IDEs is not really perfect, and that in different ways, some error messages may be hard to understand.

Jacek Szymański
Do you think maven is more of a project definition that thereby creates the build vs. ant which leaves it at a low level for you to do yourself? Kind of like, but less extreme, C vs. assembly language?
dacracot
It may be thought of as such, yes. But what is important to me, is that maven along with IDE plugins makes for a much better build tool and that's that.
Jacek Szymański
If you use Maven please consider something like the Nexus repository. That way all jars you use are copied to a fast location on your internal network.And lock a commercial release to a version so you can reproduce your deliverable :)
extraneon
Maven is more a toy tool for people trained do project one and only way.
Vladimir Dyuzhev
@dacracot With Maven, you describe your project and configure the build. The build logic is encapsulated in plug-ins. With Ant, you write your build logic. Maven is a container, a plug-in execution framework and provides plug-ins for most common tasks. Ant is a lower level scripting tool.
Pascal Thivent
@Vladimir: an alternative interpretation would be that Maven is a tool for people who learned that consistency is a good thing.
Joachim Sauer
I've used Maven since about 2005. My feelings on it move between 'indifference' and 'extreme hatred'. It does work in some cases. My biggest issues with it are 1) opacity -- who knows what the hell it's ever doing, and 2) you will waste a lot of time as soon as you need something a bit outside the norm. Ant can be verbose, but at least you can tell what it's doing. Good article on Maven: http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design/ As a parting shot: not a single person in the world wants to know what a 'mojo' is when they are just trying to get something to build.
overthink
+4  A: 

Some people like Ivy, which is a dependency managing thingy for Ant so I suppose that people coming from an Ant background will like it.

Others like Buildr. It's a JRuby thing, so if you can juggle Ruby and Java in the same projects, then I suppose it'll be interesting.

Personally, I just use Maven. It's easy to whip up a default pom.xml file and have all the build commands at your disposal. And when the project grows, you already have the infrastructure in place for running plugins and adding dependencies.

Christian Vest Hansen
Also along Buildr's lines is gant, based on Groovy. It includes Ivy. I think that build tools like Rake, Buildr, and gant are the future, because XML was never a very good basis for a language (though it's fine for hierarchical data structures where you want to make writing a parser easy).
Alan Hensel
A: 

I would urge you to start with your requirements when considering the right tool. Each project is different, the tool you use should reflect the problem space not the fashion.

That being said, I think for general use ant is still probably the best general tool for building java applications. It is often used effectively with other tools for dependency management but there we go again skirting off into a solution without a problem.

The very good news, is that if your process are good switching build tools is a fairly painless process - lesson - start with a good process scaled to the problem at hand.

Scott James
+1  A: 

I really like SCons, which is a build tool whose configuration files are all just Python scripts. This will appeal to anyone who knows Python or similar scripting languages. SCons is designed to work well with Java as well as C/C++ and other languages, and I've been very satisfied with it in the past.

Because SCons files are written in Python, you can write arbitrary Python code if you find yourself needing to do anything special. However, if you're completely unfamiliar with Python, then there will possibly be a higher learning curve than trying to extend Ant or something similar to do what you want.

Eli Courtwright
+1  A: 

Maven2 seems to be the up and coming thing.

For our projects however we are migrating back to ant wherever feasible.

Maven2 requires quite a bit of knowledge to get it exactly the way you want, and Maven2 versions seem to handle classpaths differently.

And it is a pain to check all licenses included in the dependencies of the dependencies which may get drawn in.

And may have a slower start-up time, as you need to figure out the dependencies yourself, but at least it's easily readable. No magic going on here :)

If you do use maven, give a thought to an internal repository like Nexus. That way your software is not dead if some libraries decide to go away from the net*.

*We got burned with maven1; the ibiblio maven1 repository redirects and maven1 does not support redirects :(

extraneon
The checking of dependencies isn't unique to Maven. You have the same kind of dependencies-of-dependencies in ant. The only difference is that you need to track them manually in ant, while Maven will tell you what they are.
Joachim Sauer
A: 

You will find already some answers in What are some good java make utilities?.

PhiLho
+9  A: 

Ant is still a major player. In my experience, it is dominant. Plus, with Ivy, it handles some of Maven's strengths. IMO, Ant will become a framework for other tools: XML is too rigid (see link below).

Maven 2 is also a major player. I know people who quite like it and bristle at criticisms that were true for Maven 1 (it has come a long way).

Groovy is offering some cool stuff in the build space, because they build on Ant. Gant is used in Grails, but may be subsumed into Gradle. These can be used for Java as well.

At the risk of pimping my own blog, here is a post about Gant and Gradle. Here is a link to the very current debate about their future.

Michael Easter
As a follow-up, Gradle has trounced Gant. Gradle is definitely the primary Groovy-based build tool, and is a true contender as best-of-breed in general.
Michael Easter
+5  A: 

hi there,

in the enterprise, ant is still the entrenches player. dependencies don't change fast. unlike open source projects that keep moving to fairly newest version of dependent jars, MOST enterprises try NOT to change their dependencies too fast. Given that, maven's advantages are NOT too much compared to ant.

Then again, if you want some of maven's features, ant folks have ivy (http://ant.apache.org/ivy/) for the dependencies feature.

IF you want to continue using ant, get hold of "ANT IN ACTION", 2nd edition so that you can use ant to the best productivity.

Good luck,

anjanb
I'm using Maven in a way where dependencies rarely change. And once you pinned them all down, Maven doesn't change without you explicitly requesting it. And every once in a while when you want to change it, it's very nice to be able what that means (dependencies-of-dependencies and all that) and being able to upgrade easily.
Joachim Sauer
+4  A: 

You also have Gant. Gant is Groovy + Ant, you can write your tasks in plain groovy and you can also call any ant task. If you are a Java shop and want to reuse the ant skills you have but dislike XML, I recommend Gant, it is ver easy to setup and you can embed it in ant (and also call gant from ant).

Miguel Ping
be careful with gant -- groovy debugging is pretty bad right now, and makes gant pretty much trial and error (neat idea though, and with a good debugger, it could be great)
Scott Stanchfield