6 ms·

"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build

by jamieb 14y ago

"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to do it. You may think you need to do it, you probably don't. Maybe what you need is a more powerful deployment system, or something that takes over after your java/scala/whatever is built. If you're building perl, C, C++, sure, maven isn't going to do it for you. If you're building java, you're sorted. My favorite is when this sequence happens (I have seen it first hand): 1. Maven is this external system that we have no control over. 2. We will write our own system that will be awesome. 3. Wow, look, every project uses our Build System! 4. Oh, look, someone on project X changed B.S. and now Projects A-N don't work! 5. We will lock down B.S. so only the one person who wrote it can change it! 6. ... 7. B.S. is this internal system that we have no control over! 8. ... 9. Can we add support for merging war files? 10. No that'll take weeks, and Bob isn't available anyway. I'm sure you can fuck that up just as well using Ruby. Go for it. I work in a java shop currently. There's got to be a hundred of us. Every single one uses an IDE. When I use maven, my IDE just works. eclipse, intellij, netbeans all support maven. Want to put a bunch of files in a common war to share? maven has a merge-war plugin and intellij and eclipse know what it means: they both build projects that copy the files just like maven would do. Better yet, as you edit those files, no matter where they are, both eclipse and intellij update the files in the deploy target and they are available when you refresh your browser. There is a huge amount of investment in making this stuff work. This is convention over configuration. No tool can do this with Ant (or Ruby) unless it runs the Ant and the Ruby, and then you've side stepped the IDE and reduced them to dumb text editors. With an Ant project, the IDE can't know that when I edit file A, it is transmogrified into file Z. (If it could, it could solve the halting problem). With Maven, the IDE implements convention, and so it know that File A is compiled to File B and then must be copied to location Z because its part of a merged war. Add JRebel to the equation and pretty much any change to the code is immediately runnable. Its dangerously easy to spike away instead of writing tests!

spullara 14y ago
This is so right that I feel like I live in a different universe from someone that wants to write code in their build system. If you do write your own build system, make sure it outputs a pom.xml file so I can still use maven.
crazytony 14y ago
Putting a concrete plugin version into your pom.xml helps with #1. It's solved 95% of the issues we were having with Maven.
gchpaco 14y ago
If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily). - integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?). - code coverage analysis (yes, there's a Maven plugin. You ever used it?). - FindBugs style analysis (yes, there's a Maven plugin. You ever used it?). - interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things. - C code (through JNI or anything else, a perfectly reasonable thing to want to do). - deployment. From bitter personal experience it is possible to get so wrapped up in this that you think you have achieved something amazing when you finally finish, when it could have been done in a few hours in make or rake. "Oh, but you can integrate it with your IDE!" The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests. Everything else they do with command line calls, just like it was Ant.
- timv 14y ago
  You can add pretty much anything to do with CORBA to your list. Yes there are plugins for it, but they only work in the most trivial of cases. The original article was helpful to clarifying for me why I have such a low opinion of maven - the project I was working on when Maven came out was a large complex codebase and we'd built lots of interesting things into our Ant build files. I could not work out how to ever do those sorts of things in Maven.

by jamieb 14y ago

spullara 14y ago

This is so right that I feel like I live in a different universe from someone that wants to write code in their build system. If you do write your own build system, make sure it outputs a pom.xml file so I can still use maven.

crazytony 14y ago

Putting a concrete plugin version into your pom.xml helps with #1. It's solved 95% of the issues we were having with Maven.

gchpaco 14y ago

If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily). - integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?). - code coverage analysis (yes, there's a Maven plugin. You ever used it?). - FindBugs style analysis (yes, there's a Maven plugin. You ever used it?). - interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things. - C code (through JNI or anything else, a perfectly reasonable thing to want to do). - deployment. From bitter personal experience it is possible to get so wrapped up in this that you think you have achieved something amazing when you finally finish, when it could have been done in a few hours in make or rake. "Oh, but you can integrate it with your IDE!" The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests. Everything else they do with command line calls, just like it was Ant.

timv 14y ago
You can add pretty much anything to do with CORBA to your list. Yes there are plugins for it, but they only work in the most trivial of cases. The original article was helpful to clarifying for me why I have such a low opinion of maven - the project I was working on when Maven came out was a large complex codebase and we'd built lots of interesting things into our Ant build files. I could not work out how to ever do those sorts of things in Maven.