4 ms·

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

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.
- kunley 17y ago
  Unfortunately maven has a reputation in the "enterprise". So, one of my coworkers chose it as a build & configuration tool for a production system which is physically firewalled. He happily ignored fact that maven won't be able to download dependencies. Yeah, production system had to be built on place and subsequent configuration changes have to be driven by maven (think of all mandays purchased so that devs could write their plugins for stuff which could be done in makefiles in minutes). So how this guy delivered his app to production? By uploading about 600MB of .m2/repository. Guess what. Nobody complained. Luckily I don't contract that company anymore.

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.
kunley 17y ago
Unfortunately maven has a reputation in the "enterprise". So, one of my coworkers chose it as a build & configuration tool for a production system which is physically firewalled. He happily ignored fact that maven won't be able to download dependencies. Yeah, production system had to be built on place and subsequent configuration changes have to be driven by maven (think of all mandays purchased so that devs could write their plugins for stuff which could be done in makefiles in minutes). So how this guy delivered his app to production? By uploading about 600MB of .m2/repository. Guess what. Nobody complained. Luckily I don't contract that company anymore.