Maven or Ivy for Managing Dependencies from Ant?

Question

Hi, I was wondering about the best way to manage projects dependencies from ant. What are the pros and cons of the Maven Ant task and of Ivy?

Answer 1

I know that one advantage of Ivy is that it can use different kinds of repositories. Maven is typically very rigid in the format of the repository it will use. That's all I know.

Answer 2

Since what you're wanting to do is add dependency management to an existing Ant project, that's precisely what ivy's designed to do. Dependency management is a big part of maven, but far from all of it. Maven is more of a project-oriented tool that does several other things in addition to dependencies. It would be worth considering if you were planning to migrate to maven and use additional maven features as well, but it's a bit much if all you'd use it for is to spin off ant.

Your type of dependencies and your expectations for how they behave will also make a difference. Pulling third-party dependencies is almost trivial in maven, while ivy excels in rebuilding your own dependent components. In either case, the tools won't provide decent build, versioning, and repository policies, those are still up to you and needed to get the configuration right.

Answer 3

If your long term goal is to migrate to using Maven to manage the entire build process (which one might intend to do for new greenfield projects), then I heartily recommend using Maven pom.xml files to manage dependencies on behalf of ant build.xml files. The end result is that both your greenfield projects and your legacy projects are then all using the same mechanism to manage dependencies. And it turns out Maven really does a better job of managing dependencies for ant build.xml files than does Ivy.

Prior to adopting Maven as our flagship build tool, I had a developer attempt to use Ivy in combination to existing ant build.xml files. This was most frustrating experience that very soon lead us to reject Ivy. We went ahead with an adoption of Maven. Our greenfield projects began to be built with the stock Maven approach, etc.

However, I went back to the ant legacy projects and started using the Maven ant task to define classpath definitions (and occasionally other ant property definitions pulled in from the pom.xml). This turned out to be a most superlative experience. The existing ant build.xml files need only be modified slightly to use Maven ant integration to define any classpath that were in use in the build.xml file. All dependencies required by the project became defined in an accompanying pom.xml file that gets processed by Maven via the ant task incorporated into the build.xml files.

Maven scopes can be used to fine tune classpath definitions such that one suitable for compiling, or running unit test, or for packaging, et al, can be established. Also, pretty much any element of something defined in the pom.xml file can be referenced as an ant property within the build.xml file.

Really with the the ant task for Maven there is no viable reason for Ivy to even exist.

Answer 4

Ant + Ivy == A campground, where people use the facilities as needed Maven == A resort, where you rely on someone else to provide services

Maven is easier for a team lacking build/integration experience, but when the team needs to diverge from Maven standards they will find themselves reaching for groovy, gradle, and the lack of solid documentation will become frustrating

Ant + Ivy will take longer to startup a project, but if the team has build/integration experience they can tailor the build system around they way they develop and release code.

In engineering... technology companies I always push for the campsite solution versus the resort.

It is amazing though that both Ant and Maven choose XML as their langauge to express build recipes with. The Java community is stuck on that XML...

Answer 5

I think this blog post covers exactly what the OP is looking for:

Why you should use the Maven Ant Tasks instead of Maven or Ivy

Answer 6

I've just spent 2 days reading through the Ivy documentation and I have to say, USE MAVEN if you have any kind of choice. Ivy is complete and utter garbage as far as I can tell. I just wasted 2 days trying to incorporate it into my build and am cutting my losses now. Why?

• Ivy is a half-assed attempt at dependency management
• Ivy documentation is a total joke
• Ivy examples and tutorial are useless

As soon as I introduced 'configurations' (read as maven profiles), Ivy started going bezerk downloading all sorts of junk I don't need then failing. The documentation for Ivy is an utter joke. Maven documentation in comparison reads like a dream. If you want an example of how impenetrable and badly written the Ivy documentation is, take a look at the reference page for configurations. These are an essential part of any build, but in Ivy they seem to be a badly designed after thought.

Answer 7

Ivy+Ant is far, far more flexible. Ivy does dependency management, period, and it does that extremely well, better than Maven. And with Ant you can pretty much put together any build system that you want.

Maven tries to control everything - the "lifecycle" (compile, test, package, etc.), where files should live, and so on. Have fun customizing plugins and the like if you don't like the "Maven way".

Maven is the answer to a question no one asked. Writing an Ant script is not hard, and Ivy gives you better dependency management than Maven. I am confused by some of the previous comments stating they couldn't get Ivy working. Ivy is quite a bit simpler than Maven to get up and running.

The Spring Framework uses Ivy in its build process. I think that can be seen as quite a vote of confidence for Ivy.