What are your impressions of Maven? [closed]

Answer 1

One of the main reasons for using any build tool is to get reproducible builds. That is to say that the build you do today can be exactly replicated in a years time. Maven, in my experience, fails horribly at the test of creating reproducible builds.

The problems stem from being a large and complex beast with many moving parts. Each part has its own release cycle, and the versions often conflict with one another and break your build. Trying to debug such a thing is very complex.

I use Maven for open source work because it produces a reasonable website relatively quickly. That is something rarely of interest to non open source developers. Even with this task I have frequently spent long periods of time trying to work out why things aren't working as expected. For the open source work I usually use ant to actually produce the build (jar) as that is reliable.

One final point. If you are writing an open source project you may have to use Maven in some way. If your project is popular then you'll need to get it in the central Maven repository, and that is much more tricky if you don't use Maven.

Answer 2

I personally really like Maven, and there are a lot of other folks that do as well. Maven2 has a much better reputation than Maven1, and there seems to be a trend in the OSS community towards it. For shops that have a lot of different projects, it really helps create consistency and you don't feel like you are reinventing the wheel with Ant scripts on every project.

To address your question, it would be good if you would at least submit your jar to the central repository. You don't have to replace your existing build process with maven, but you will have to at least maintain a POM with the dependencies for your project.

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

This will benefit your project by making it much easier for users (who use Maven or Ivy) to download and install your jar.

If you decide to use maven to do your build it will likely increase participation in your project because it will lower the barrier to entry somewhat. Once you have your project built using maven, all that is required for someone who wants to build from source is to run "mvn install". (FWIW, the same can be accomplished using Ant/Ivy to some degree).

Answer 3

Personally, I'm not a fan. I agree with most of what Charles Miller says about it being broken by design. It does solve some problems, but it also introduces others.

Ant is far from perfect, but it is a lot more robust and far better documented. It does take some discipline to use it in a modular way though (which is one of the things Maven is trying to address). I think that inventing something better than both Ant and Maven wouldn't be that difficult, but that tool doesn't seem to exist yet.

If you like Maven's dependency management but not Maven, you can get something similar in Ant using Ivy. My problem with this style of dependency management is that is fragile due to factors outside of your control. The one use case where it does make some sense is if you have lots of projects internal to your organisation that depend on each other. In this case everything is under your control and it might work quite well.

EDIT: I forgot to add that even if you don't like Maven, you can't ignore it. If you write open source libraries that other people use, they will expect them to be available in a Maven repository so that they can use them easily from their Maven builds.

EDIT2: Since you've clarified that your main interest is in providing an Open Source library to other Maven users, it's worth noting that you don't necessarily have to use Maven to achieve this. There is a set of Ant Tasks for publishing to a Maven repository. So, if you want to continue using Ant to build your project, you can do but still satisfy your Maven-using users.

Answer 4

Some friends have told me that Maven is a bit like NetBeans: both suffer from a certain stigma that was once deserved but no longer entirely valid. I hated Maven 1.x due to a lack of documentation and due to XML/Jelly.

The latter issue may be resolved, as Maven 2 is much more Java-oriented. The stigma of poor documentation remains, but I don't know if it is fair. (If it is still fair, then the Maven team has truly dropped the ball.)

Both the POM and dependency management are cool ideas, but one wonders if they will be assimilated by a newer tool, in the same way that C++ led the way to newer languages.

A final note: the dichotomy between Ant and Maven is somewhat false. Gradle and Gant are build tools in the Groovy space that have a lot to offer, even for straight-up Java projects. Because they use Groovy, the simple tasks are truly simple (in contrast to the painful XML constructions in Ant); yet they have strong integration with Ant, so there is a rich set of "hard" tasks.

Answer 5

In our company we've slowly started moving over to Maven to try to enforce a uniformity between different component builds. Right now it's a huge mash-up of ant scripts trying to do the same thing. It's worked great, integrates nicely with our build server (Hudson), and the few things that we needed to do that Maven doesn't support (or fully support), we've basically thrown in a simplified ant build xml that we attach to the build process. It plugs any functionality holes nicely and makes converting over a sinch - All you have to get working is the base compile / package process, and then you can move over any other side effects of your builds from ant slowly as you have time.

Answer 6

A major benefit of using Maven is that it externalizes the 'project object model' (hence pom.xml). The advantage of such an independent project structure is that it becomes portable across tools and IDE's.

All major IDE's have invested a lot in maven support. When you open the project in your IDE of choice, it will adopt the Maven structure and you are ready to go:

• In Eclipse: Import... Maven project...
• In IntelliJ: Open Project... browse to the pom.xml
• In Netbeans: All transparently

You typically put all IDE metadata (.iml, .project, .classpath, etc...) on the VCS ignore list.

Obviously, Continuous Integration engines benefit in a similar way from a POM based approach.

There is a learning curve and there are constraints, but you get a lot in return.