6 ms·

I don't hate Maven, and I haven't left it yet. But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to cre

by mcherm 14y ago

I don't hate Maven, and I haven't left it yet. But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to create a build tool. A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it.

jbrackett 14y ago
You should take a look at http://www.gradle.org/ http://www.gradle.org/ if you haven't already. I worked on an ant project and decided we needed to convert to a better build system. I started down the path of Maven, but Gradle changed my mind because of the conciseness. It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post.
- craigching 14y ago
  > It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post. The article mentions Gradle :-P Need to read the whole article ;-)
  - jbrackett 14y ago
    Hrmm that's embarrassing... well it's mentioned below the fold and everyone knows people don't pay attention to that stuff. :)
- meddlepal 14y ago
  Gradle has given me a lot of headaches for small projects. I keep going back to it now and then and run into performance issues with it where builds that take 10 seconds in Maven take 10 min in Gradle. It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet. It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-based build tool, but I can't justify wasting a lot of time on Gradle when I know how to do what I need to do in Maven.
  - msgilligan 14y ago
    I've used Gradle on a handful of small projects and am very surprised that you're seeing an order of magnitude difference between a Maven build and a Gradle one. Can you provide a little more detail about what the script was doing for 10 minutes?
    - meddlepal 14y ago
      Last time I used it which was right around when 1.3 was released I turned on debug logging while the project built so I could see what was causing the issues. It was hanging long periods of time around a task I had to make a fat jar. If I remember correctly it was having some real trouble with locks on Ivy caches... I tried clearing out the Gradle caches and that did not resolve the problem. Since that was a small project I was able to replace the build file with a POM and assembly descriptor be done with it. If I get some more time to play around I might go back and try and collect some more info for a bug report... I have had this issue since the late Gradle betas each time I go back to using Gradle I hope the problem is resolved.
      - msgilligan 14y ago
        Well, 1.4 claims to have improvements to dependency resolution, so soon you should be able to take another kick at the football soon. I'm growing to like Gradle more and more and haven't seen any problems like this. My major desire is for more/better plugins, but I do think this will become less of an issue. (I'm even hoping to write 1 or 2) I should also mention that GVMTool is worth checking out if you're on a UNIX-based system. An easy way to install and switch between versions of Gradle and other tools: http://gvmtool.net http://gvmtool.net
rossjudson 14y ago
So...the way that you do that in Maven is to create a plugin, which is very easy to do. There's your full flexibility, as soon as you want it. Your plugin has to play by the rules, which is a good thing. Maven's useful for more than the beginning of a project. If you're working on real-world software, you're probably not the only person who has to understand your bespoke build, if that's the way that you've chosen to go.
- eeperson 14y ago
  The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.
  - spullara 14y ago
    That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.
    - chii 14y ago
      agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your own repository server, and that comes with huge overheads. I m warming up to the idea of always mandating offline mode in maven, and then check in to the scm a preloaded repository which includes all the libs and plugins for your project, and never have to worry about external repos, or network connectivity.
      - rossjudson 14y ago
        I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over larger numbers of projects. You can also push libraries into the repository that aren't open source, and know that you've done so. Running a maven repository doesn't take much. Sonatype's basic offerings are fine and quite effective.
michaelt 14y ago
A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it. I've never seen a situation like this - but perhaps I've lived a sheltered life. Can anyone give me an example of when this would be a good design decision?
- shadowmint 14y ago
  You're generating configuration files from a database as part of your build. OR You're reading a file and using the details in that file to control your build. OR You need to loop through a set of properties and apply a specific update to each value before the build. OR You need to invoke complex build logic based on the platform you're building for (nested ifs). etc. There are lots of odd situations you end up in with real projects. The flexibility this provides comes at the cost of build complexity though. Obscure syntax and odd custom DSL's (>_> cmake, make, powershell) are bad because they introduce complexity and destroy the readability and maintainability of the build. You basically need a test suite for your build code to make sure it's building correctly. Terrible. ...but, necessary. I'm not a java guy, but writing C and C++? You need to do this stuff all of the time. scons or cmake really make life a lot easier than trying to force Makefiles to do things with their obscure lambda syntax.
  - lmm 14y ago
    >You basically need a test suite for your build code to make sure it's building correctly Absolutely, which is one of the best things about maven - because all your build steps are plugins written in standard Java, you can test it the same way you test your regular code.
berlinbrown 14y ago
I think developers are dogmatic and stick to a particular religion. I don't mind mind maven but I hate when I see an example piece of code and the only way to get it to work is complicated maven(pom) script. Then I have to spend a hour trying to figure out what is in the maven script. And you end up with only 2 or 3 jars (log4j and commons-logging junit and some other jar). Why don't you just give me the version I need in a bundled jar and I can go about my coding. My only fear with maven is when things break or someone how you have a wrong version of maven that the script requires or downloads fail or something else. If the script fails you can't do anything. And who knows, the only that was required was just compiling the java source with minimal dependencies.
- frugalmail 14y ago
  Not sure what you're complaining about specifically, but maven has the ability to generate bundled jars when the app author includes the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/ http://maven.apache.org/plugins/maven-assembly-plugin/ ). Then you would just type mvn assembly:assemble
jamieb 14y ago
"Because eventually your project is probably going to need it." If it has it, someone is going to think they need it. A year later you have 10,000 lines of Ant and nobody to maintain it. Building code is not hard. Discipline is hard.

by mcherm 14y ago

jbrackett 14y ago

You should take a look at http://www.gradle.org/ http://www.gradle.org/ if you haven't already. I worked on an ant project and decided we needed to convert to a better build system. I started down the path of Maven, but Gradle changed my mind because of the conciseness. It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post.

craigching 14y ago
> It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post. The article mentions Gradle :-P Need to read the whole article ;-)
- jbrackett 14y ago
  Hrmm that's embarrassing... well it's mentioned below the fold and everyone knows people don't pay attention to that stuff. :)
meddlepal 14y ago
Gradle has given me a lot of headaches for small projects. I keep going back to it now and then and run into performance issues with it where builds that take 10 seconds in Maven take 10 min in Gradle. It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet. It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-based build tool, but I can't justify wasting a lot of time on Gradle when I know how to do what I need to do in Maven.
- msgilligan 14y ago
  I've used Gradle on a handful of small projects and am very surprised that you're seeing an order of magnitude difference between a Maven build and a Gradle one. Can you provide a little more detail about what the script was doing for 10 minutes?
  - meddlepal 14y ago
    Last time I used it which was right around when 1.3 was released I turned on debug logging while the project built so I could see what was causing the issues. It was hanging long periods of time around a task I had to make a fat jar. If I remember correctly it was having some real trouble with locks on Ivy caches... I tried clearing out the Gradle caches and that did not resolve the problem. Since that was a small project I was able to replace the build file with a POM and assembly descriptor be done with it. If I get some more time to play around I might go back and try and collect some more info for a bug report... I have had this issue since the late Gradle betas each time I go back to using Gradle I hope the problem is resolved.
    - msgilligan 14y ago
      Well, 1.4 claims to have improvements to dependency resolution, so soon you should be able to take another kick at the football soon. I'm growing to like Gradle more and more and haven't seen any problems like this. My major desire is for more/better plugins, but I do think this will become less of an issue. (I'm even hoping to write 1 or 2) I should also mention that GVMTool is worth checking out if you're on a UNIX-based system. An easy way to install and switch between versions of Gradle and other tools: http://gvmtool.net http://gvmtool.net

rossjudson 14y ago

So...the way that you do that in Maven is to create a plugin, which is very easy to do. There's your full flexibility, as soon as you want it. Your plugin has to play by the rules, which is a good thing. Maven's useful for more than the beginning of a project. If you're working on real-world software, you're probably not the only person who has to understand your bespoke build, if that's the way that you've chosen to go.

eeperson 14y ago
The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.
- spullara 14y ago
  That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.
  - chii 14y ago
    agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your own repository server, and that comes with huge overheads. I m warming up to the idea of always mandating offline mode in maven, and then check in to the scm a preloaded repository which includes all the libs and plugins for your project, and never have to worry about external repos, or network connectivity.
    - rossjudson 14y ago
      I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over larger numbers of projects. You can also push libraries into the repository that aren't open source, and know that you've done so. Running a maven repository doesn't take much. Sonatype's basic offerings are fine and quite effective.

michaelt 14y ago

A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it. I've never seen a situation like this - but perhaps I've lived a sheltered life. Can anyone give me an example of when this would be a good design decision?

shadowmint 14y ago
You're generating configuration files from a database as part of your build. OR You're reading a file and using the details in that file to control your build. OR You need to loop through a set of properties and apply a specific update to each value before the build. OR You need to invoke complex build logic based on the platform you're building for (nested ifs). etc. There are lots of odd situations you end up in with real projects. The flexibility this provides comes at the cost of build complexity though. Obscure syntax and odd custom DSL's (>_> cmake, make, powershell) are bad because they introduce complexity and destroy the readability and maintainability of the build. You basically need a test suite for your build code to make sure it's building correctly. Terrible. ...but, necessary. I'm not a java guy, but writing C and C++? You need to do this stuff all of the time. scons or cmake really make life a lot easier than trying to force Makefiles to do things with their obscure lambda syntax.
- lmm 14y ago
  >You basically need a test suite for your build code to make sure it's building correctly Absolutely, which is one of the best things about maven - because all your build steps are plugins written in standard Java, you can test it the same way you test your regular code.

berlinbrown 14y ago

I think developers are dogmatic and stick to a particular religion. I don't mind mind maven but I hate when I see an example piece of code and the only way to get it to work is complicated maven(pom) script. Then I have to spend a hour trying to figure out what is in the maven script. And you end up with only 2 or 3 jars (log4j and commons-logging junit and some other jar). Why don't you just give me the version I need in a bundled jar and I can go about my coding. My only fear with maven is when things break or someone how you have a wrong version of maven that the script requires or downloads fail or something else. If the script fails you can't do anything. And who knows, the only that was required was just compiling the java source with minimal dependencies.

frugalmail 14y ago
Not sure what you're complaining about specifically, but maven has the ability to generate bundled jars when the app author includes the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/ http://maven.apache.org/plugins/maven-assembly-plugin/ ). Then you would just type mvn assembly:assemble

jamieb 14y ago

"Because eventually your project is probably going to need it." If it has it, someone is going to think they need it. A year later you have 10,000 lines of Ant and nobody to maintain it. Building code is not hard. Discipline is hard.