5 ms·

Why Dustin Sallings Doesn't Use Maven

27 points by mbrubeck 17y ago

yesimahuman 17y ago
Maven and Ant are unnecessarily verbose. I find Makefiles and CMake far simpler. Maybe it's just the XML I'm sick of.
- viraptor 17y ago
  I always thought about Ant as `make + native Java plugins`. Is there anything else it can do that doesn't fit in that description?
  - gchpaco 17y ago
    Correct dependency handling and implicit rules, for one. The amount of effort required to translate %.o: %.c into ant is unbelievable. You can use the depend tasks but those require you to know your dependencies ahead of time and take explicit action to check them. It is more a measure of how unbelievable maven 2 is that ant looks pretty good in comparison, because ant is terrible at most things other than running javac.
Lewisham 17y ago
The thing I do like about Maven is that you're pretty much guaranteed that if the build works on your machine, it'll work for everyone else too. This might be because it stops you doing anything stupid, but removes power too. Like blunt scissors. I'm going to be switching to Buildr for my next project, if only because it can pull in dependencies that aren't in the Maven repos, which would mean it's even more likely to work on someone else's machine... as long as I don't do anything stupid :)
- donw 17y ago
  Like hell you are. You're guaranteed that it will work on a machine that has network access to the same resources, that has a similar enough version of Java, and with permissions to write wherever the hell Maven decides it wants to put things. From my point of view as a sysadmin, Maven is a tool that was invented to punish people in my profession. Want to test in a sandbox separated from your SCM for security reasons? Good luck. How about grabbing a defunct project from the Internet because it does what you need, and discovering that it won't build because it wants a dependency that it can't download, and so rather than just letting you supply the dependency in a way that will satisfy the compiler, you have to make Maven happy as well. I shouldn't have to fight this much with a build tool to do simple things, like BUILD THE APPLICATION. This is one of the few rants I've posted here, but fuck Maven. It's an overcomplicated answer to a problem that the mindset that led to Maven development created in the first place.
  - brown9-2 17y ago
    Want to test in a sandbox separated from your SCM for security reasons? Good luck. How in the world does the choice of build tool affect if you can test your application (once it's built) in a sandbox environment? If you can compile and package the application, you should be able to upload it to whatever environment you want.
    - donw 17y ago
      Unless that 'build tool' is Maven, which wants to be build tool, dependency resolver, project manager, SCM, and very likely the Pope. Maven really doesn't like being cut off from its network repositories.
      - brown9-2 17y ago
        You can pretty easily set up your build to package up your app and all it's dependencies as a tar.gz/zip/whatever during the package phase. This is what you can export to your sandbox environment. Or does what you would want to test in the sandbox include the building and dependency resolution phases?
  - Lewisham 17y ago
    Well, you can specify which Java to compile against (and if the target machine didn't have the right Java, you were SOL anyway). The network resources is a good point, but I'd rather Maven try to go and get a dependency and get it 90% of the time than worry about making my users go and do it, or, worse, considering packaging other libraries along with my own source code. That's not cool. I am confused about your comment about defunct project dependencies. My understanding was the Maven repos didn't delete anything, so if you can get the project, you can get its dependencies. I've never come across a Maven project that couldn't find its dependencies. Maven also wants to write to ~/.m2/ by default, so your users shouldn't have a permission problem. It sounds to me that you are just scared about Maven doing all this other stuff that you never told it to do, and you have requirements that Maven doesn't fulfil easily. Maven is overly complex. Like I said, I intend to move to Buildr for my next project. However, there are problems that it solves for Java that other tools simply didn't, and Buildr and Ivy wouldn't exist without it and its repository structure, which Java sorely needed. I am willing to give it a pass for that. There's always room to get better, but I'd rather use Maven than Ant.
Daniel_Newby 17y ago
+1 for the guy sitting at the window story. Maven killed the ANTLR parser generator for me. I wanted to try making a compiler and ANTLR looked like the bee's knees. So I download it, try to build it using the official instructions, and package downloads start zooming across my screen. "What in the nine green hells of Zorgon is this?!," I think to myself. Then Maven blew up. "Oh, crap," I think. Then I look at the config file to see how to fix it. XML. "Oh, CRAP!" I think. I try to do a clean rebuild. Maybe a stray file got into version control, maybe an HTTP server horked during the downloads, that sort of thing. Maven could no longer read its own repository. "!@#$!@$ !@#%% !@#@$@!! !@#@#@ $#!$$!@," I say out load. And delete ANTLR. Life's too short to be stepping through a debugger for the build tool for your build tool for you build tool.
- brown9-2 17y ago
  Why don't you just download the binaries from the ANTLR site? http://www.antlr.org/download/antlr-3.2.jar http://www.antlr.org/download/antlr-3.2.jar for "Complete ANTLR 3.2 jar; all tools, runtime, etc..." http://www.antlr.org/download.html http://www.antlr.org/download.html
  - donw 17y ago
    Perhaps he wanted to build from source, for whatever reason? Certainly a 'build tool' should make this, well, easy.
    - brown9-2 17y ago
      Yeah it should. And the project should make sure it's easy to build from source as well. I just tried to download Antlr source from the site and build it and I get errors about how they've configured a plugin which needs to connect to their SCM but they haven't configured their part. I can see that Maven has a sharp learning curve, and that it can be frustrating when you want to get just one task done - I think it shines when you are working in an environment with many projects with inter-dependencies between them - but some blame should be pointed here at the Antlr project authors, who haven't made sure that you could cleanly build the source on their site.
mml 17y ago
Maven, of any version, is fiendishly idiotic. The fact that the now almost extinct jellyscript is considered a good thing by the author gives me pause. Really, I can't fathom why anyone persists in using any ant-based system when there are many better choices (like suicide). If you'd like a short chuckle, look up the origins of ant.
mtrimpe 17y ago
How come all Maven criticism is completely off the mark? @mml: Maven is in no way ant-based. It has an ant-plugin but that's pretty much all. @dustin: The release thing? It's called the 'release-plugin'.
- mml 17y ago
  Maven is clearly ant++. The concept of XML as buld descriptor language is clearly lifted direcly from ant. It's a tragedy that the java environment is so comparatively weird that make & cousins weren't obvious choices to build java projects. I spent a majority of the last decade & change dealing with ant and maven builds on million line projects. My hatred for both is from years of bitter experience. Sorry, I hate them both with the zed-like fury of a billion suns.
  - jbooth 17y ago
    My opinion of Maven is the same as Winston Churchill's opinion of democracy: "It's the worst system, aside from all the other systems." I've seen plenty of makefiles bomb out on systems that were different from the system they were written for -- it's hard to have that problem with Maven. And the idea of a versioned repo that stores multiple revisions of all of your components is awesome, provided you actually use it correctly and don't leave everything at 0.1-SNAPSHOT forever. The problem it's solving is inherently hellish, so while there could be better ways of solving it, Maven's the least crappy one I've seen so far.
- dlsspy 17y ago
  I'm aware of the release plugin -- I also was when I wrote it. I didn't see much of a difference between it and the SCM plugin. I replied to such criticism on my post, so I'll just paste that response here: I'm aware of the release plugin. It adds automation to the stuff I said I didn't like in "My Build System is Not My SCM" I do not want "make" tagging my releases. That's not its job and it does not have the information required to do it correctly. My tags look like this: http://pastebin.com/1vQnC78C http://pastebin.com/1vQnC78C Note the following: * List of changes * List of contributors * List of bugs fixed * GPG signature on the tag ensuring cryptographic certainty of the source The maven release plugin cannot do that. It is worse than what I have now.

27 points by mbrubeck 17y ago

yesimahuman 17y ago

Maven and Ant are unnecessarily verbose. I find Makefiles and CMake far simpler. Maybe it's just the XML I'm sick of.

viraptor 17y ago
I always thought about Ant as `make + native Java plugins`. Is there anything else it can do that doesn't fit in that description?
- gchpaco 17y ago
  Correct dependency handling and implicit rules, for one. The amount of effort required to translate %.o: %.c into ant is unbelievable. You can use the depend tasks but those require you to know your dependencies ahead of time and take explicit action to check them. It is more a measure of how unbelievable maven 2 is that ant looks pretty good in comparison, because ant is terrible at most things other than running javac.

Lewisham 17y ago

The thing I do like about Maven is that you're pretty much guaranteed that if the build works on your machine, it'll work for everyone else too. This might be because it stops you doing anything stupid, but removes power too. Like blunt scissors. I'm going to be switching to Buildr for my next project, if only because it can pull in dependencies that aren't in the Maven repos, which would mean it's even more likely to work on someone else's machine... as long as I don't do anything stupid :)

donw 17y ago
Like hell you are. You're guaranteed that it will work on a machine that has network access to the same resources, that has a similar enough version of Java, and with permissions to write wherever the hell Maven decides it wants to put things. From my point of view as a sysadmin, Maven is a tool that was invented to punish people in my profession. Want to test in a sandbox separated from your SCM for security reasons? Good luck. How about grabbing a defunct project from the Internet because it does what you need, and discovering that it won't build because it wants a dependency that it can't download, and so rather than just letting you supply the dependency in a way that will satisfy the compiler, you have to make Maven happy as well. I shouldn't have to fight this much with a build tool to do simple things, like BUILD THE APPLICATION. This is one of the few rants I've posted here, but fuck Maven. It's an overcomplicated answer to a problem that the mindset that led to Maven development created in the first place.
- brown9-2 17y ago
  Want to test in a sandbox separated from your SCM for security reasons? Good luck. How in the world does the choice of build tool affect if you can test your application (once it's built) in a sandbox environment? If you can compile and package the application, you should be able to upload it to whatever environment you want.
  - donw 17y ago
    Unless that 'build tool' is Maven, which wants to be build tool, dependency resolver, project manager, SCM, and very likely the Pope. Maven really doesn't like being cut off from its network repositories.
    - brown9-2 17y ago
      You can pretty easily set up your build to package up your app and all it's dependencies as a tar.gz/zip/whatever during the package phase. This is what you can export to your sandbox environment. Or does what you would want to test in the sandbox include the building and dependency resolution phases?
- Lewisham 17y ago
  Well, you can specify which Java to compile against (and if the target machine didn't have the right Java, you were SOL anyway). The network resources is a good point, but I'd rather Maven try to go and get a dependency and get it 90% of the time than worry about making my users go and do it, or, worse, considering packaging other libraries along with my own source code. That's not cool. I am confused about your comment about defunct project dependencies. My understanding was the Maven repos didn't delete anything, so if you can get the project, you can get its dependencies. I've never come across a Maven project that couldn't find its dependencies. Maven also wants to write to ~/.m2/ by default, so your users shouldn't have a permission problem. It sounds to me that you are just scared about Maven doing all this other stuff that you never told it to do, and you have requirements that Maven doesn't fulfil easily. Maven is overly complex. Like I said, I intend to move to Buildr for my next project. However, there are problems that it solves for Java that other tools simply didn't, and Buildr and Ivy wouldn't exist without it and its repository structure, which Java sorely needed. I am willing to give it a pass for that. There's always room to get better, but I'd rather use Maven than Ant.

Daniel_Newby 17y ago

+1 for the guy sitting at the window story. Maven killed the ANTLR parser generator for me. I wanted to try making a compiler and ANTLR looked like the bee's knees. So I download it, try to build it using the official instructions, and package downloads start zooming across my screen. "What in the nine green hells of Zorgon is this?!," I think to myself. Then Maven blew up. "Oh, crap," I think. Then I look at the config file to see how to fix it. XML. "Oh, CRAP!" I think. I try to do a clean rebuild. Maybe a stray file got into version control, maybe an HTTP server horked during the downloads, that sort of thing. Maven could no longer read its own repository. "!@#$!@$ !@#%% !@#@$@!! !@#@#@ $#!$$!@," I say out load. And delete ANTLR. Life's too short to be stepping through a debugger for the build tool for your build tool for you build tool.

brown9-2 17y ago
Why don't you just download the binaries from the ANTLR site? http://www.antlr.org/download/antlr-3.2.jar http://www.antlr.org/download/antlr-3.2.jar for "Complete ANTLR 3.2 jar; all tools, runtime, etc..." http://www.antlr.org/download.html http://www.antlr.org/download.html
- donw 17y ago
  Perhaps he wanted to build from source, for whatever reason? Certainly a 'build tool' should make this, well, easy.
  - brown9-2 17y ago
    Yeah it should. And the project should make sure it's easy to build from source as well. I just tried to download Antlr source from the site and build it and I get errors about how they've configured a plugin which needs to connect to their SCM but they haven't configured their part. I can see that Maven has a sharp learning curve, and that it can be frustrating when you want to get just one task done - I think it shines when you are working in an environment with many projects with inter-dependencies between them - but some blame should be pointed here at the Antlr project authors, who haven't made sure that you could cleanly build the source on their site.

mml 17y ago

Maven, of any version, is fiendishly idiotic. The fact that the now almost extinct jellyscript is considered a good thing by the author gives me pause. Really, I can't fathom why anyone persists in using any ant-based system when there are many better choices (like suicide). If you'd like a short chuckle, look up the origins of ant.

mtrimpe 17y ago

How come all Maven criticism is completely off the mark? @mml: Maven is in no way ant-based. It has an ant-plugin but that's pretty much all. @dustin: The release thing? It's called the 'release-plugin'.

mml 17y ago
Maven is clearly ant++. The concept of XML as buld descriptor language is clearly lifted direcly from ant. It's a tragedy that the java environment is so comparatively weird that make & cousins weren't obvious choices to build java projects. I spent a majority of the last decade & change dealing with ant and maven builds on million line projects. My hatred for both is from years of bitter experience. Sorry, I hate them both with the zed-like fury of a billion suns.
- jbooth 17y ago
  My opinion of Maven is the same as Winston Churchill's opinion of democracy: "It's the worst system, aside from all the other systems." I've seen plenty of makefiles bomb out on systems that were different from the system they were written for -- it's hard to have that problem with Maven. And the idea of a versioned repo that stores multiple revisions of all of your components is awesome, provided you actually use it correctly and don't leave everything at 0.1-SNAPSHOT forever. The problem it's solving is inherently hellish, so while there could be better ways of solving it, Maven's the least crappy one I've seen so far.
dlsspy 17y ago
I'm aware of the release plugin -- I also was when I wrote it. I didn't see much of a difference between it and the SCM plugin. I replied to such criticism on my post, so I'll just paste that response here: I'm aware of the release plugin. It adds automation to the stuff I said I didn't like in "My Build System is Not My SCM" I do not want "make" tagging my releases. That's not its job and it does not have the information required to do it correctly. My tags look like this: http://pastebin.com/1vQnC78C http://pastebin.com/1vQnC78C Note the following: * List of changes * List of contributors * List of bugs fixed * GPG signature on the tag ensuring cryptographic certainty of the source The maven release plugin cannot do that. It is worse than what I have now.