3 ms·
> Maven assumes there is one right way to build for everyone A lot of people have this opinion (and prefer Ant, Gradle or something else as a result). I do not
by timv 13y ago
> Maven assumes there is one right way to build for everyone
A lot of people have this opinion (and prefer Ant, Gradle or something else as a result). I do not share this view. I like that Maven is opinionated about things like project structure.
Well his opinion is perfectly true - Maven does assume there is one right way to build for everyone. You're disagreeing about whether it's a bad thing.
And here's the deal - for the 95% (or more) of projects where "The Maven Way" works, it's a good thing, for all the reasons you've stated.
But not every project fits into that, and one of Maven's limitations is that once you start to push at its boundaries, it falls apart. It doesn't provide enough flexibility to be able to stretch it into places it wasn't intended to go. And so, once your project his that point you either need to fight the tool, or throw it out and use something else. Neither is particularly desirable.
Maven is one of many tools that isn't cool but is certainly good enough.
For most cases, yes, but not always. No matter who you are, your experience is not universal enough to draw those conclusions for other people's projects.
How much time do you spend editing build files anyway?
Personally? Enough to have run into all sorts of limitations in Maven.
Not everyone is working on "Maven WAR project". There are projects with full time build engineers. Even on small projects (in terms of lines of code) if the artifacts you're producing are non-standard, then you can spend days (or even weeks) wrestling with maven to get the project under control.
Maven makes the easy things trivial, the average things easy, but it also makes the hard things nearly impossible. For the 95% that's a fine trade-off, but if you're not in that group then Maven is not going to be your friend.
- mtrimpe 13y agoMaven is very, very customizable. I've built ETL libraries that use a completely custom lifecycle (pre-/post- extract, extract, transform & load) in Maven with a directory structure to match. If you can't code in Java that will be hard, but it's similar to me complaining about Puppet because I can't figure out it's architecture fast enough since I don't know Ruby well enough. P.S. Not saying you can't code in Java, but the original author did indicate the mere fact that it was Java was problematic.
- johlrogge 13y agoYes, the original author (me) did indicate that Java was a bad choice but not for the reasons you assume here but for the reasons I clearly stated in the post :) Most of them being related to that Java is a compiled language so you often find yourself in a situation where you wonder about plugin internals but the actual source the plugin was built from is elsewhere. That in combination with that extensions needs to be compiled and distributed which requires infrastructure to "build the build". Sure it's easy to google and download the source, even recompile, setup a place where the plugins can be used from (custom and patched ones) but it is still extra overhead that would not be needed at all with (for instance) an interpreted language. An interpreted language is simply a more sensible choice for these kind of things. The developers of SBT understood this and made sure the buildfile and plugins are distributed as source and compiled by SBT to make this extra step go away even if the buildfile is written in Scala.
- mtrimpe 13y agoIndeed. From what I can tell it seems that your post is actually taking aim at Java and it's ecosystem and how Maven embodies that more than against Maven itself. You're framing it as an attack against just Maven though..