What are your impressions of Maven?

Question

I am considering using Maven for a Java open source project I manage.

In the past, however, Maven has not always had the best reputation. What are your impressions of Maven, at this time?

Answer 1

Maven can be used to manage the entire lifecycle of your project, from the start to the deployment. If those are what you need, then Maven is the right tool. If you're just looking for a tool for dependency management, you may want to look into Ant's Ivy too.

It has been used in most of the projects that I worked on and.. although sometimes irritating (the configurations and documentation), it has saved me a lot of time. Most of the Apache's Java-based projects use Maven.

Whether Maven works, it really depends on what you want it to do for you.

yc

Answer 2

There a few very good things about maven:

• Archetypes: A kind of start up (base) project (very useful) that a lot of people make. In businesses where you tend to recreate the same kind of stuff over and over, it is extremely practical.
• Dependency management: You really have to try it to love it. Ivy is a good compatible tool too.
• Life cycle management: Without a entire IDE, you can do everything from the command line with maven and by that I mean: compile, package, test, deploy, etc. And its possible to make some step dependent on others. Although I think that the defaults are not the best, this part is customizable.

Additionally, maven can also do some ant stuff.

The downside for me is really about the fact that it is hard to port a project to it. It is best to start from scratch. Also, maven extensively uses plug-ins to do its job, but not everything is perfect in that regard and there aren't plug-ins for everything yet.

Answer 3

I love Maven and I use it all the time. Part of the reason is that it is very simple to set up via Eclipse's XML plugins (it has an XSD that is very descriptive). Maven is great for dependency management as well, as it lets you download jars from repositories and exclude transitive dependencies where applicable. It also has a built in site:site goal which is great for producing project websites with applicable reports.

Maven is great for projects that are just starting, but it does have its expected format of your source code. If you start your project with Maven, knowing what it can do immediately, it will help you greatly. But you should definitiely research it. "Out of the box", maven can do great things, and plugins for it abound. However, some things ANT handles better than Maven, and if there's not a Maven plugin for it, it may be difficult to handle in Maven. But, you can always learn to create your own Maven plugin as well.

See Better Builds With Maven for a good guide to maven.

Oh, and these comments apply to Maven 2, I've never used Maven 1.

Answer 4

@MetroidFan2002: Maven 1 is deprecated and it's arguably more stable than Maven 2 (although less features). Writing Jelly script is definitely a bad idea.

yc

Answer 5

For an open-source project, Maven has some advantages, especially for your contributors (eg mvn eclipse:eclipse).

If you do go with Maven, the one rule you must follow religiously is: don't fight the tool. Layout your project exactly how Maven recommends, follow all its conventions and best practices. Every little fight you get into with Maven is a day you won't be spending writing code for your project.

Also consider up front where you want to deploy your artifacts (are you going to host your own repository?).

And don't be afraid to go with something other than Maven (eg Ant). The success of your project will be the project itself, not its build tool (so long as you choose a best-of-breed build tool, which both Ant and Maven are).

Answer 6

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 7

we're using maven for a really big project (more than 15 modules) and we tried hard not to fight the tool but

1) maven solves the 90% of common problems, but if you're struggling the other 10% it is always a mess to fiddle with

2) life-cycle management is a mess. Even if you choose a correct phase for your stuff to happen, sometimes it doesn't work. And you don't know the f***ing why

3) we fight hard but eventually we gave up: we use ant from maven. Sometimes we use even ant to call maven. Now don't even try to think we sucks: if only you could see the complexities of certain steps in our build process... it is just that maven gets in your ways more often than not for building complex projects.

4) the local repository management is a burden. Artifactory is not good. And other similar products.

All in all: I would suggest Ant (maybe with Ivy if you want dependencies management, but I never tried that)

Bye Stefano

Answer 8

I had the misfortune of working with Maven when it was transitioning from 1.x to 2.x. It pretty much consumed 100% of the time of one of our more senior team members. We eventually scrapped it.

However, more recently I had a chance to revisit maven, and I would say it has improved. One of my main issues has been the lack of good documentation, but after reading "Maven: the definitive guide", I would say its much easier to fathom.

Along with the m2eclipse plugin for eclipse, managing dependencies becomes a doddle - it has an excellent dependency visualisation tool.

Overall, I would say Maven is a great tool starting out on a project, but may start to lose its way once your build begins to gain complexity.

Answer 9

If your project is 'simple', then maven lets you get up and running quite quickly. By simple I mean you have a bunch of code, some resources, some test classes and it all goes together with some 3rd party jars to make an application.

The moment you want to do something unusual that is in some way specific to your own project then you will end up spending all your time trying to make maven do what you want it to and none of your time working on your code. This for me defeats the purpose of using a clever build system.

Maven is also dreadful for helping you diagnose problems when it's not working. And the build scripts are unreadable screeds of unintuitive and unnatural xml, which may of course be what you prefer and are looking for (If you have ant-vision).

I love maven. Maven is full of goodness and promise. I also hate maven.

Edit:

Oh, and the maven plugin for eclipse is flippin' brilliant.

Answer 10

matt raible has a blog entry http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason.

i have heard that most people that use maven do not like it.

Answer 11

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 12

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 13

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 14

We have a community of Open Source developers working independently on their own projects. Several of these projects use libraries from other projects. Without dependency management we run into cyclic dependencies in jars. ant did not help with these problems (this was before Ivy, which I haven't used). By using maven, and deploying jars, we are managing to reduce the dependencies and get many fewer problems. So we have benefited enormously from having a dependency management tool and personally I have found that the effort to use maven is very much worth it.

Answer 15

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 16

The documentation is getting better, and m2eclipse is simply awesome. But someone above pointed out the "broken by design" article. He made some good points. While I personally think maven is a better tool than ant, in the long run our experience will make maven3 a better tool than maven2.

I couldn't live without it. I can go to ANY machine in the world with an internet connection, a JDK and Maven 2, check out my git repository, and run 'mvn test', and it'll build. Say that about any other build tool, I dare you. :-)

Answer 17

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.