4 ms·

I love Maven and have been what I'd call a power user for at least five years. However, the first time I heard of it (and tried it), I hated it. Until you get

by smoyer 14y ago

I love Maven and have been what I'd call a power user for at least five years. However, the first time I heard of it (and tried it), I hated it. Until you get your head around the idea that you're describing "what" you're building rather than how to build it, you'll feel an impedance mismatch. And I didn't begin to feel mastery with Maven until I started writing plug-ins. If you really want to understand your tool, then try extending it. I've never had issues with Maven builds missing files, etc. and I'm not really sure how that happens. On the other hand, the fact that the project structure is almost always the same from project to project lets me successfully dive into projects I've never touched. But Maven can be complex, especially if you're not careful to segment your project into sub-projects and modules. There are parts that are best learned by working with someone who's already mastered the build system. In any case, I think make/autoconf are harder to grasp than Maven, and I've never hated it the way I do when I'm programming in XML (Ant).

sreque 14y ago
"Until you get your head around the idea that you're describing "what" you're building rather than how to build it, you'll feel an impedance mismatch." Trust me, us maven haters understand declarative programming just fine. There is no impedence mismatch. Maven the build tool is simply an inferior solution with several superior alternatives. After discovering Buildr, I've never wanted to go back to Maven, and I'm willing to trust that Gradle (Groovy), Leiningen (Clojure), and SBT (Scala), are all also superior to Maven while integrating well with Maven's dependency system.
- smoyer 14y ago
  Dependency management in Maven is amazing ... yet I don't find myself wanting to go back to Ant with Ivy.
- jamieb 14y ago
  "I'm willing to trust that Gradle (Groovy), Leiningen (Clojure), and SBT (Scala), are all also superior to Maven while integrating well with Maven's dependency system." Except that they don't. They can consume it, but they can't produce it. Or do they make pom files now? Or do you not care about pom files because you'll never publish your source?
  - jdminhbg 14y ago
    Not a Groovy or Scala person, but I can report that Leiningen for Clojure definitely produces pom files with `lein pom`.
  - _pdeschen 14y ago
    Gradle does generates pom.
  - theatrus2 14y ago
    SBT can produce .pom files (along with Ivy artifacts)
emmelaich 14y ago
Like so many, I love and hate it. I can see that it helps at the large scale - big projects, many of them. It also helps people come in cold to a project. On the other hand, unfortunately it doesn't scale to the low end. I had a task just to transform a jar file. With Maven it took hours of scratching my head, finding the assembly plug-in, having Maven download 100Mb of stuff; all to do what would take a minutes of development time and executation time total to do in Python or Perl. That makes you scream inside.
- craigching 14y ago
  I agree with pretty much everything you're saying. I wish maven could learn from leiningen and make base maven work like it does. It's so easy with leiningen to create a new project and start coding. With maven, I pretty much need a multi-module project for even simple things (mostly because I code Java using eclipse and eclipse needs a workspace above my projects generally speaking) and doing that is a lot of incantation to get up and running.
- timv 14y ago
  Heh, I have the totally opposite view... Maven is perfectly fine for small projects, but a totally waste of time at the large scale. If your project is a few hundred classes, that use some-popular-web-framework and some-orm, and get packaged into a single WAR file, then Maven is simple, it works and it lets you avoid thinking about the build. If your project is thousands of classes using a variety of technologies (Corba, JMS, Web, etc) with layers of dependencies, then Maven should help, since it should allow you to manage all those technologies through a similar process, but it just collapses under the strain. The bits that tend to get in the way (some of this is probably specific to Maven 2, but I got burnt enough back then that I'm not willing to revisit it all and see what happens with Maven 3) Despite multi-module being the right way to solve things (both the Maven team's opinion and mine) it works really badly. If you want to compile & test your whole project each time, then you're all good, but if you want to cut your build process down and just recompile the modules that you're working on, you're going to lose most of that time saving in trying to wrangle Maven into doing things properly. The main issue is the dependency management is all built around the idea that you only ever depend on jar files in a repository. So, in a multi-module project where you actually want to depend on "the source code sitting in a sibling directory", things go wrong. Despite Maven's theories about having a standardised project model, too much ends up being left to the plugin authors. If you're using more esoteric plugins (e.g. the Corba IDLc plugins) then you'll get caught out by issues that the plugin authors didn't think of. Plugin-X looks for a resource file on the classpath (but only the main classpath, not the test one), Plugin Y looks for its resource file on the file system, Plugin Z will look for a file on the classpath, but crashes if that file is inside a jar, but you need to reference a jar because the file is coming from another module in your multi-module project, and you can only express dependencies on jar files. So to work around that you add a step in your build to unpack the jar into a temporary location and add that location to the classpath. And you though maven wasn't procedural. One artifact per module is a nice idea thought up by people who assumed that their experiences were diverse enough to solve everyone else's problems. Unsurprisingly they're wrong. But to keep maven happy you split your project into dozens of modules each with 1 artifact. But that makes your build even slower, and creates even more issues with managing the dependencies between modules. And even if you do that, you still end up hacking your pom to create more than 1 artifact because sometimes you really need to. Handling test support code in a multi-module project is painful. Well written tests need supporting code. But that is neither "test" code (because test code is not exported out of your module) nor "main" code (because you don't want to ship it). So either, you create extra modules to handle testing. In the worst case, you need to split each module into 3 - the main code, the test support code, and the actually tests. So, in summary, the pain you're feeling with a small project, is just multiplied exponentially as your project grows.

by smoyer 14y ago

sreque 14y ago

"Until you get your head around the idea that you're describing "what" you're building rather than how to build it, you'll feel an impedance mismatch." Trust me, us maven haters understand declarative programming just fine. There is no impedence mismatch. Maven the build tool is simply an inferior solution with several superior alternatives. After discovering Buildr, I've never wanted to go back to Maven, and I'm willing to trust that Gradle (Groovy), Leiningen (Clojure), and SBT (Scala), are all also superior to Maven while integrating well with Maven's dependency system.

smoyer 14y ago
Dependency management in Maven is amazing ... yet I don't find myself wanting to go back to Ant with Ivy.
jamieb 14y ago
"I'm willing to trust that Gradle (Groovy), Leiningen (Clojure), and SBT (Scala), are all also superior to Maven while integrating well with Maven's dependency system." Except that they don't. They can consume it, but they can't produce it. Or do they make pom files now? Or do you not care about pom files because you'll never publish your source?
- jdminhbg 14y ago
  Not a Groovy or Scala person, but I can report that Leiningen for Clojure definitely produces pom files with `lein pom`.
- _pdeschen 14y ago
  Gradle does generates pom.
- theatrus2 14y ago
  SBT can produce .pom files (along with Ivy artifacts)

emmelaich 14y ago

Like so many, I love and hate it. I can see that it helps at the large scale - big projects, many of them. It also helps people come in cold to a project. On the other hand, unfortunately it doesn't scale to the low end. I had a task just to transform a jar file. With Maven it took hours of scratching my head, finding the assembly plug-in, having Maven download 100Mb of stuff; all to do what would take a minutes of development time and executation time total to do in Python or Perl. That makes you scream inside.

craigching 14y ago
I agree with pretty much everything you're saying. I wish maven could learn from leiningen and make base maven work like it does. It's so easy with leiningen to create a new project and start coding. With maven, I pretty much need a multi-module project for even simple things (mostly because I code Java using eclipse and eclipse needs a workspace above my projects generally speaking) and doing that is a lot of incantation to get up and running.
timv 14y ago
Heh, I have the totally opposite view... Maven is perfectly fine for small projects, but a totally waste of time at the large scale. If your project is a few hundred classes, that use some-popular-web-framework and some-orm, and get packaged into a single WAR file, then Maven is simple, it works and it lets you avoid thinking about the build. If your project is thousands of classes using a variety of technologies (Corba, JMS, Web, etc) with layers of dependencies, then Maven should help, since it should allow you to manage all those technologies through a similar process, but it just collapses under the strain. The bits that tend to get in the way (some of this is probably specific to Maven 2, but I got burnt enough back then that I'm not willing to revisit it all and see what happens with Maven 3) Despite multi-module being the right way to solve things (both the Maven team's opinion and mine) it works really badly. If you want to compile & test your whole project each time, then you're all good, but if you want to cut your build process down and just recompile the modules that you're working on, you're going to lose most of that time saving in trying to wrangle Maven into doing things properly. The main issue is the dependency management is all built around the idea that you only ever depend on jar files in a repository. So, in a multi-module project where you actually want to depend on "the source code sitting in a sibling directory", things go wrong. Despite Maven's theories about having a standardised project model, too much ends up being left to the plugin authors. If you're using more esoteric plugins (e.g. the Corba IDLc plugins) then you'll get caught out by issues that the plugin authors didn't think of. Plugin-X looks for a resource file on the classpath (but only the main classpath, not the test one), Plugin Y looks for its resource file on the file system, Plugin Z will look for a file on the classpath, but crashes if that file is inside a jar, but you need to reference a jar because the file is coming from another module in your multi-module project, and you can only express dependencies on jar files. So to work around that you add a step in your build to unpack the jar into a temporary location and add that location to the classpath. And you though maven wasn't procedural. One artifact per module is a nice idea thought up by people who assumed that their experiences were diverse enough to solve everyone else's problems. Unsurprisingly they're wrong. But to keep maven happy you split your project into dozens of modules each with 1 artifact. But that makes your build even slower, and creates even more issues with managing the dependencies between modules. And even if you do that, you still end up hacking your pom to create more than 1 artifact because sometimes you really need to. Handling test support code in a multi-module project is painful. Well written tests need supporting code. But that is neither "test" code (because test code is not exported out of your module) nor "main" code (because you don't want to ship it). So either, you create extra modules to handle testing. In the worst case, you need to split each module into 3 - the main code, the test support code, and the actually tests. So, in summary, the pain you're feeling with a small project, is just multiplied exponentially as your project grows.