maven - is it a good / common practice to use it only for dependency mgmt and then let the ant do everything else..?

I am newbie with maven.

Other than its use for managing dependencies, I am finding little use for it.

It was getting so h开发者_如何学JAVAard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...) I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..

Is such a combination common? I am thinking of making it permanent in my project.

Other than its use for managing dependencies, I am finding little use for it.

That's because you don't get it :) Dependencies management is only a small part of Maven, Maven has really much more. Quoting Maven: The Definitive Guide:

Maven is a project management tool which encompasses a project object model, a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at defined phases in a lifecycle. When you use Maven, you describe your project using a well-defined project object model, Maven can then apply cross-cutting logic from a set of shared (or custom) plugins.

Maven uses convention over configuration with lots of useful defaults (directory locations, a defined life-cycle, a set of common plugins that know how to build and assemble software), Maven provides a common interface to build project (unlike Ant, you know how to do things like running tests, packaging, etc with every project, no need to open the build script to find out how it's done), Maven implements reuse through maven plugins (build logic is embedded into plugins for DRY purpose, you don't have to repeat yourself over and over, you don't have to copy/paste parts of your build scripts), Maven has a Project Object Model that allows you to describe your project through meta-data (this enables dependency management, remote repositories, reuse of build logic, tool integration, artifacts search...).

So, because Maven provides a lingua franca or shared language for project management, comparing Maven vs. Ant (+ Ivy if you want), Maven vs. Buildr, Maven vs. Gradle is like comparing apples to oranges, the comparison is just irrelevant.

Is such a combination common? I am thinking of making it permanent in my project.

Well, no, that's really not the maven way of doing things. This might seem tempting (because you have the feeling that you regain control because you understand what is happening with Ant) but you are actually repeating yourself again and losing all advantages of Maven. Sure, there is some learning curve with Maven and I'm not saying you'll learn it in one night but once you'll get it, you'll feel the power. I'd thus recommend to keep trying, to ask questions on the mailing list or here on SO, to read the Maven Book, etc. But don't give up.

So you re-did what Maven gives you for free by writing Ant Tasks within a pom.xml?

Besides doing the Dep-Mgmt, Maven will compile the sources, run all test cases and package the whole thing as jar file for you with no extra configuration. That's the default.

It is not common to enrich a pom.xml with Ant clutter. However, some special tasks or legacy Ant tasks are sometimes embedded into the pom.xml lifecycle, but these are exceptions and not the common case.

What exactly is hard when writing a pom.xml?

I wonder, because most of the time you will do this once for a project and not struggle with it all the time. Also, most IDEs have support for creating the minimum pom.xml, which is just a few lines anyway.

I've tried Maven, personally for home projects and professionally at my workplace, and... I hate it. I must admit I don't have a lot of experience, but it doesn't feel good. I get the idea Maven is a less-than-perfect implementation of a good idea. I'll probably get flamed by Maven enthusiasts, but this is my personal opinion.

I think Maven comes into its own in organizations that deal with a network of interrelated projects, like Apache does; where dependencies tend to change a lot and need to be quite explicitly specified to avoid "jar version hell". For isolated projects dependent on a few seldom changing jars, I find it overly intrusive.

To answer your question: I've read forum and blog posts on the Internet of other people doing exactly what you propagate. They use Maven for dependency management and then do their building with Ant. This undermines some of the benefits Maven is supposed to bring, such as the fact that a "normal" build is simpler to specify in Maven than Ant. However, I think you can be encouraged by the fact that you're not the only person with this idea, and it is indeed working for some other people.

I'd like to give you links to quotes, but I came across this stuff in the past few weeks and didn't collect references.

I'm a Maven fan, but it's not without its problems. Some of the issues I remember (and still fight):

• Just like Ant, it has a magical syntax that can be hard to understand. If you're familiar with Any you may forget that, but lots of Ant tasks are terribly documented. The same is true for Maven. One of the reasons I eventually switched to Maven, though, is that for many of the mojos (similar to Ant tasks), you don't have to understand how to configure them. You just have to put the various pieces in the right place (which can be as hard as configuring a task...).
• The automatic dependency management is amazing!... when it works. When you have to use non-Maven dependencies (like Hadoop) it becomes a problem. You either have to reference them as system scope dependencies, find somebody else who has packaged them, or package them yourself. And you eventually need to setup your own Maven proxy, like Nexus. And that's a whole extra hassle.
• Maven is a lot of trouble on non-network or isolated LANs. The automagic is great, as long as you're networked.

It was getting so hard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...) I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..

Well. you can use maven archetype plugin to generate pom :)

Is such a combination common? I am thinking of making it permanent in my project.

JBoss Seam uses Maven internally to handle dependencies and do some targets in Maven. It's a big project that grew up with Ant, and now is difficult to build entire project solely in Maven, but that is going to happen in near future.

If you just need dependency management with Ant, you could give Ivy a try. Maven is a tool for managing the whole lifecycle of the build process.

Personally, I find Maven a nice tool once you get over the learning curve since you can standardize the build process for a lot of projects and there are a lot of great add-ons (particularly for code analysis tools). However, it's very possible that you do enough custom stuff with your build that the Ivy + Ant combo makes more sense.

Honestly, I would love to see a dependency management tool that implemented that part of Maven, specifically as a command line tool. For everything BUT dependency management, I find Maven to be absolutely awful if you're doing anything but exactly what the most general case is. Every time I try to do something that isn't "normal" (system/acceptance tests, etc), I run into a brick wall due to

• either horrid documentation,
• being told it's "not the maven way" (when it's a task that needs to happen, and "the way" shouldn't be a factor), or
• being told to wait for the next version of maven, because maybe it'll be supported then.

I'd love to have a command line tool that can implement the "I need this as a dependency, go get it" functionality of Maven, possibly even using the pom.xml files of various packages. Then I could just use that in a Makefile and happy :)

Simple answer to the question posed: YES <-- click the link for details and reasoning.