Why maven? What are the benefits?

What are the main benefits of using maven compared to let's say ant ? It seems to be more of a annoyance than a helpful tool. I use maven 2, with plain Eclipse Java EE (no m2eclipse), and tomcat.

Supporters of maven believe that

1. Maven lets you get your package dependencies easily

2. Maven forces you to have a standard directory structure

In my experience

1. Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.

2. Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.

Or am I just doing it wrong ? Please point me to the right direction, I'm all ears.

> Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.

Not that hard... for toy projects. But the projects I work on have many, really many, of them, and I'm very glad to get them transitively, to have a standardized naming scheme for them. Managing all this manually by hand would be a nightmare.

And yes, sometimes you have to work on the convergence of dependencies. But think about it twice, this is not inherent to Maven, this is inherent to any system using dependencies (and I am talking about Java dependencies in general here).

So with Ant, you have to do the same work except that you have to do everything manually: grabbing some version of project A and its dependencies, grabbing some version of project B and its dependencies, figuring out yourself what exact versions they use, checking that they don't overlap, checking that they are not incompatible, etc. Welcome to hell.

On the other hand, Maven supports dependency management and will retrieve them transitively for me and gives me the tooling I need to manage the complexity inherent to dependency management: I can analyze a dependency tree, control the versions used in transitive dependencies, exclude some of them if required, control the converge across modules, etc. There is no magic. But at least you have support.

And don't forget that dependency management is only a small part of what Maven offers, there is much more (not even mentioning the other tools that integrates nicely with Maven, e.g. Sonar).

> Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.

First, why do you use Maven like this? I don't. I use my IDE to write tests, code until they pass, refactor, deploy, hot deploy and run a local Maven build when I'm done, before to commit, to make sure I will not break the continuous build.

Second, I'm not sure using Ant would make things much better. And to my experience, modular Maven builds using binary dependencies gives me faster build time than typical monolithic Ant builds. Anyway, have a look at Maven Shell for a ready to (re)use Maven environment (which is awesome by the way).

So at end, and I'm sorry to say so, it's not really Maven that is killing your productivity, it's you misusing your tools. And if you're not happy with it, well, what can I say, don't use it. Personally, I'm using Maven since 2003 and I never looked back.

Maven can be considered as complete project development tool not just build tool like Ant. You should use Eclipse IDE with maven plugin to fix all your problems.

Here are few advantages of Maven, quoted from the Benefits of using Maven page:

> ### Henning > > - quick project setup, no complicated build.xml files, just a POM and go > - all developers in a project use the same jar dependencies due to > centralized POM. > - getting a number of reports and metrics for a project "for free" > - reduce the size of source distributions, because jars can be > pulled from a central location > > ### Emmanuel Venisse > > - a lot of goals are available so it isn't necessary to develop some > specific build process part contrary > to ANT we can reuse existing ANT tasks > in build process with antrun plugin > > > ### Jesse Mcconnell > > - Promotes modular design of code. by making it simple to manage mulitple > projects it allows the design to be > laid out into muliple logical parts, > weaving these parts together through > the use of dependency tracking in pom > files. > - Enforces modular design of code. it is easy to pay lipservice to modular > code, but when the code is in seperate > compiling projects it is impossible to > cross pollinate references between > modules of code unless you > specifically allow for it in your > dependency management... there is no > 'I'll just do this now and fix it > later' implementations. > - Dependency Management is clearly declared. with the dependency > management mechanism you have to try > to screw up your jar > versioning...there is none of the > classic problem of 'which version of > this vendor jar is this?' And setting > it up on an existing project rips the > top off of the existing mess if it > exists when you are forced to make > 'unknown' versions in your repository > to get things up and running...that or > lie to yourself that you know the > actual version of ABC.jar. > - strong typed life cycle there is a strong defined lifecycle that a > software system goes thru from the > initiation of a build to the end... > and the users are allowed to mix and > match their system to the lifecycle > instead of cobble together their own > lifecycle.. this has the additional > benefit of allowing people to move > from one project to another and speak > using the same vocabulary in terms of > software building > > ### Vincent Massol > > - Greater momentum: Ant is now legacy and not moving fast ahead. Maven is > forging ahead fast and there's a > potential of having lots of high-value > tools around Maven (CI, Dashboard > project, IDE integration, etc).

Figuring out dependencies for small projects is not hard. But once you start dealing with a dependency tree with hundreds of dependencies, things can easily get out of hand. (I'm speaking from experience here ...)

The other point is that if you use an IDE with incremental compilation and Maven support (like Eclipse + m2eclipse), then you should be able to set up edit/compile/hot deploy and test.

I personally don't do this because I've come to distrust this mode of development due to bad experiences in the past (pre Maven). Perhaps someone can comment on whether this actually works with Eclipse + m2eclipse.

Maven is one of the tools where you need to actually decide up front that you like it and want to use it, since you will spend quite some time learning it, and having made said decision once and for all will allow you to skip all kinds of doubt while learning (because you like it and want to use it)!

The strong conventions help in many places - like Hudson that can do wonders with Maven projects - but it may be hard to see initially.

edit: As of 2016 Maven is the only Java build tool where all three major IDEs can use the sources out of the box. In other words, using maven makes your build IDE-agnostic. This allows for e.g. using Netbeans profiling even if you normally work In eclipse

Maven advantages over ant are quite a few. I try to summarize them here.

Convention over Configuration
Maven uses a distinctive approach for the project layout and startup, that makes easy to just jump in a project. Usually it only takes the checkount and the maven command to get the artifacts of the project.

Project Modularization
Project conventions suggest (or better, force) the developer to modularize the project. Instead of a monolithic project you are often forced to divide your project in smaller sub components, which make it easier debug and manage the overall project structure

Dependency Management and Project Lifecycle
Overall, with a good SCM configuration and an internal repository, the dependency management is quite easy, and you are again forced to think in terms of Project Lifecycle - component versions, release management and so on. A little more complex than the ant something, but again, an improvement in quality of the project.

What is wrong with maven?
Maven is not easy. The build cycle (what gets done and when) is not so clear within the POM. Also, some issue arise with the quality of components and missing dependencies in public repositories.
The best approach (to me) is to have an internal repository for caching (and keeping) dependencies around, and to apply to release management of components. For projects bigger than the sample projects in a book, you will thank maven before or after

Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success. For a more detailed look at how Maven can help you with your development process please refer to The Benefits of Using Maven.

Maven is a powerful project management tool that is based on POM (project object model). It is used for projects build, dependency and documentation. It simplifies the build process like ANT. But it is too much advanced than ANT. Maven helps to manage- Builds,Documentation,Reporing,SCMs,Releases,Distribution.

• maven repository is a directory of packaged JAR file with pom.xml file. Maven searches for dependencies in the repositories.

I've never come across point 2? Can you explain why you think this affects deployment in any way. If anything maven allows you to structure your projects in a modularised way that actually allows hot fixes for bugs in a particular tier, and allows independent development of an API from the remainder of the project for example.

It is possible that you are trying to cram everything into a single module, in which case the problem isn't really maven at all, but the way you are using it.

This should have been a comment, but it wasn't fitting in a comment length, so I posted it as an answer.

All the benefits mentioned in other answers are achievable by simpler means than using maven. If, for-example, you are new to a project, you'll anyway spend more time creating project architecture, joining components, coding than downloading jars and copying them to lib folder. If you are experienced in your domain, then you already know how to start off the project with what libraries. I don't see any benefit of using maven, especially when it poses a lot of problems while automatically doing the "dependency management".

I only have intermediate level knowledge of maven, but I tell you, I have done large projects(like ERPs) without using maven.