20

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?

dbr
  • 165,801
  • 69
  • 278
  • 343
Julien Chastang
  • 17,592
  • 12
  • 63
  • 89
  • 1
    What is the project? It will make the question a bit more answerable, and less subjective/argumentative – dbr Nov 20 '08 at 11:03
  • I run an open-source project called charts4j (http://charts4j.googlecode.com) and I am constantly asked to integrate with Maven. But I am not convinced it is worthwhile, hence my question. Thanks for all the helpful responses I have received so far. – Julien Chastang Nov 20 '08 at 16:13
  • possible duplicate of [Why does Maven have such a bad rep?](http://stackoverflow.com/questions/861382/why-does-maven-have-such-a-bad-rep) – Hardy Jul 21 '13 at 11:03

18 Answers18

37

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).

Matt Quail
  • 6,189
  • 2
  • 23
  • 20
  • 5
    Maven follows the "Convention over Configuration" paradigm much like Ruby on Rails and it's competitors. So it's assuming you've accepted their conventions and will work well in that regard (most of the time). – Spencer Kormos Nov 20 '08 at 16:15
  • 4
    "Don't be afraid to go with something other than Maven" So true! Most people who choose Maven .. because they are too afraid of appearing to be "low skilled" by going with Ant. – rk2010 May 13 '12 at 14:18
29

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.

Dan Dyer
  • 53,737
  • 19
  • 129
  • 165
  • 1
    Dan, I'd also take a look at Mercury if you need to interact with the Maven repository format. Mercury has support for some of the more advanced usage scenarios like PGP sig verification and security: http://people.apache.org/~ogusakov/sites/mercury-ant/mercury-ant-tasks/howto.html – Tim O'Brien Mar 31 '09 at 22:59
12

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.

izb
  • 50,101
  • 39
  • 117
  • 168
  • >I love maven. Maven is full of goodness and promise. I also hate maven. My thoughts exactly. – Michael Neale Dec 17 '08 at 22:23
  • This is more a problem with plugin documentation for various plugins. There is certainly a sense that there are some critical plugins such as the Release plugin which cause people some consternation whenever they need to do something very custom. We're working every day to address doco gaps. – Tim O'Brien Mar 31 '09 at 23:02
10

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.

toolkit
  • 49,809
  • 17
  • 109
  • 135
  • 1
    Thanks for the vote of confidence in the book, we're still trying to develop the content and address the critical lack of clarity. – Tim O'Brien Mar 31 '09 at 23:01
8

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.

Loki
  • 29,950
  • 9
  • 48
  • 62
5

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.

JodaStephen
  • 60,927
  • 15
  • 95
  • 117
  • The issue with lack of repeatability was addressed last year with the 2.0.9 release. Until that time, Maven could (and would) download the latest version of a core dependency. After the 2.0.9 release, the versions of the core plugins are locked down. You should take a second look. – Tim O'Brien Mar 31 '09 at 23:04
  • On a complex project its hard to avoid using third-party plugins to fill the gaps in the core Maven plugin set. Those extra plugins are often in SNAPSHOT state and they can change without notice and break your build. Maven builds are still not guaranteed to be repeatable. – KevinS Jun 17 '09 at 22:46
  • @KevinStembridge: Well, Maven docs clearly indicate that SNAPSHOTS are "bleeding-edge unstable" and only meant for use during development (of that code). If a project does not offer releases of their artifaces, you can't really blame that on Maven. Actually, I can't think of any plugin we use that is only available as a SNAPSHOT. – sleske Jan 18 '12 at 08:59
  • @sleske: If you have to rely on a snapshot version of a plugin to get the functionality or bug fixes you need, then you are subject to non-repeatable builds. I'm not holding Maven responsible for the project management of third-party plugins but its not much consolation to say that my build was not repeatable but its not Maven's fault. Having said that, I don't really think that it happens often enough to be very time-consuming and over time I expect this issue to become less of a problem. There are many other problems with Maven that are much more time-consuming than non-repeatable builds. – KevinS Jan 18 '12 at 10:32
  • @KevinStembridge: True, if some projects only offers a SNAPSHOT, you may have to live with that. Note, btw, that you could always grab the sources (assuming they are available), and install a non-SNAPSHOT version to your local repo, then use that as your dependency. Once upstream does a real release, you can switch your deps to it anytime you like. – sleske Jan 18 '12 at 10:35
4

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).

Ken Liu
  • 22,503
  • 19
  • 75
  • 98
3

The JavaPosse discussed Maven quite a bit in recent podcast #217. The consensus was that it's very restrictive in how it allows you to structure your projects, but that its usage is growing, and that it may offer a cross-IDE standard for representing a project.


Update—Javaposse also hosted an informative session at last spring's Java Roundup 09 entitled, "Maven with Pain?" I laughed (in horrified sympathy) as, toward the end of the recording, one of the participants related how a plugin update broke their build—two days before a production release.


I've steered clear of it, honestly, in large part because I find the name irritating. However, the ability to manage dependencies of third-party libraries is appealing.


Update—for those that have an irrational disdain for my irrational opinion, let me show you what "maven" conjures up in my mind:

Edna Mode

Yes, in my mind, Edna Mode is the epitome of "maven". And I don't want her in my build—too bossy!

What would be a better name? Invented words are best for their pin-point Google results. For a good impression, root them in real words with a positive connotation.

erickson
  • 265,237
  • 58
  • 395
  • 493
  • 1
    So Maven is annoying and not JEveryFramework4J? It's a wonder you program in Java at all! =D – Spencer Kormos Nov 20 '08 at 16:12
  • 1
    Those aren't great either. But Maven has a strong association in my mind with an unpleasant image of an abrasive, smirking, know-it-all... telling me how to run my build! Argh! – erickson Nov 20 '08 at 19:42
  • 3
    You don't like the name? What if we create another project that repackages Maven under another name? What name would be acceptable? – Tim O'Brien Mar 31 '09 at 23:06
  • 1
    Those who really use Maven, spending time extending it or debugging it shall know - Maven is a PITA but we need it. – yclian Jul 18 '10 at 18:38
  • @TimO'Brien It's not just that; I don't know who this guy is, but he summarizes several significant issues: [why_everyone_eventually_hates_or_leaves_maven](http://www.reddit.com/r/programming/comments/176o53/why_everyone_eventually_hates_or_leaves_maven) – erickson Mar 03 '14 at 23:20
3

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.

2

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.

Jan
  • 9,397
  • 13
  • 47
  • 52
  • Portable Code Formatting support would make the picture complete. – Jan Jul 29 '10 at 11:16
  • 1
    :D Portable? right... I have seen developers using Mavens being very scared to even upgrade to newest version of their IDE. Why? Because the newer version might not with their Maven plugin.. and then of course.. they won't be able to "compile!!" God forbid u upset your local Maven repo or settings. – rk2010 May 13 '12 at 14:21
1

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.

Darsant
  • 76
  • 4
1

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. :-)

Chris K
  • 11,996
  • 7
  • 37
  • 65
  • I could go to ANY machine in the world with an internet connection, a JDK and Ant, check out my git repository, and run ant build, and it'll build. I could go to ANY machine in the world with an internet connection, a JDK and Gradle, check out my git repository, and run gradle build, and it'll build. I could go to ANY machine in the world with an internet connection, a JDK and Maven, check out my git repository, and run mvn install, and it'll build... almost always. – KevinS Jan 18 '12 at 10:42
  • You might have a point with Gradle, but I'll take umbrage you can do that with ant without some effort (unless you're not using any 3rd party libs or include them in your repo). Okay, maybe ant gives this to you (nearly 18 months later) today. That said, I had some recent difficulties getting a Minecraft plugin to work with Maven. Mostly because some 3rd party libs got way out of date and some repositories disappeared. But thanks for the poke - a good reminder one must stay humble. Things do change in time, after all. :-) Cheers! – Chris K Jan 20 '12 at 02:22
  • 1
    I couldn't resist the dare :) But the fact is, separating your dependency jars from your source code does not save time in the long run (or even the short term). With Ant/Ivy and with Gradle you have the ability to declare and download your dependencies, as with Maven, but then you also get the option to store them in your project beside your source code and commit them to your source repository. This is a much more reliable setup. – KevinS Jan 22 '12 at 00:29
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

yclian
  • 1,490
  • 14
  • 22
1

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

kindoblue
  • 151
  • 1
  • 7
  • 2
    May I suggest looking at Nexus (http://nexus.sonatype.org/) for your repository needs. It was far better than other repository I tried in my experience. – Michel Nov 20 '08 at 13:06
1

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.

Ray Tayek
  • 9,841
  • 8
  • 50
  • 90
  • 1
    "i have heard that most people that use maven do not like it." That seems like a pretty unfounded suggestion. If most people didn't like something, why would they use it at all? – Brian Fox Apr 25 '09 at 21:28
  • i heard this in one of raible's video's. i have no experience with it myself. – Ray Tayek Apr 25 '09 at 22:38
  • 1
    @BrianFox: he's right. I have to use maven and I don't like it. – madoki Nov 30 '11 at 08:31
  • 1
    @BrianFox Most people use it because Apache forces it into everybody's psyche. And Apache libraries are almost as trusted as Java JDK itself. The 'Architects' in companies, think its the best thing since sliced bread because Maven promises so much. But these Architects dont realize its a "Build System" not a "Ant Replacement". Which then causes all the mess when this "build System" is forced on to others without there being a need (or support) for "build system" – rk2010 May 13 '12 at 14:11
  • 1
    Also - nobody I know really knows how to use Maven. So everybody is literally at the mercy of Maven fanboys on forum like this one. – rk2010 May 13 '12 at 14:16
1

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.

Michael Easter
  • 23,733
  • 7
  • 76
  • 107
0

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.

MetroidFan2002
  • 29,217
  • 16
  • 62
  • 80
-1

@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

yclian
  • 1,490
  • 14
  • 22