Finally got to write down my gripes with Maven, with a catchy title ;-)
Maven is broken by design
46 plus ones
Shared publicly•View activity
View 27 previous comments
- In such a way that the build-helper-maven-plugin would be unable to add new source roots?Oct 7, 2013
- I understand that there are special conditions where that could be temporarily needed, but I don't think it is a good practice at all to have different source root than the standard ones.
In maven, if needed, the different source root should be moved into the src/main/java of a different maven project.
It is very important that any contributor to a project like GWT is able to find the sources in the standard directories and nothing unless very special exceptions outside of this layout.
The cost of having sources "away" is paid with higher cost in getting into the project and being able to contribute.Oct 7, 2013
- build-helper was just an example, it equally applies to any plugin that generate sources and/or resources: the Maven Way™ is to generate things into target/ and then add the folder as a new source root, but that new source root is only known to Maven after the plugin has run.
but that's the crux of the problem, that the model used in the execution phase is mutable.Oct 7, 2013
- If only that was the only issue… or even the main one…
That one issue hurts toolability, but could have much deeper implications: a plugin can completely change the build lifecycle, add plugins, remove others, reconfigure everything, at any point in the course of the build.
Re. comprehension, Gradle or SBT plugins are good candidates. You have to know how these plugins work just like you have to know how Maven plugins work.Oct 7, 2013
- Apologies for entering the thread here with what is essentially a hat held in front of me, but I'm curious on whether the last half a year or so has matured any of these thoughts?
I can say that I am not a huge fan of maven, but I have yet to really be swayed by the gradle enthusiasm. A lot of this comes down to just how well IDEA does handle basic maven builds. My vantage is that more harm is done by over eager "maven modularization" of projects than just maven.
I'm probably blinded a bit by just how "non horrible" things go if you stick with the overwhelming convention. I make no claims that they are great, but the cost of moving to another build system is one that is tough to really consider when many of the more exotic needs of the proponents just don't seem to apply.
Also, I made the mistake recently of reading up on autotools. That seems to be a system that, while not even close to pretty, did seem to have the majority of the concerns in project build covered. Years ago.
At any rate, I am particularly interested in tooling support. IDEA chokes more than a little on 400+ "modules", but if you can resist the urge to introduce that many "pom.xml" files, it seems to run pretty well off of a maven structure. Sadly, the only tooling support I have played with in gradle has been on a super polyglot system that involved npm, bower, and gulp all coordinated through a gradle build. Supposedly it was easy'ish to setup. Hoping that IDEA will understand this full build is... well, not going as smoothly as desired.
Thanks!May 22, 2014
- When I first adopted maven, it wasn't because it was good. At the time, I quite frankly thought it was a really horrible implementation of a good idea. The same went for SVN. They were both better than what we had, so I went with it.
I say maven is broken, but it can be fixed. It would simply be no different than creating a new tool. You simply say maven X is either completely incompatible with older maven, or you write adapters for the older plugin model. And then you do a whole heck of a lot of refactoring. You could also create a maven pom converter.
The idea of creating a build system (gradle), which is driven out of a programming language, is a REALLY bad idea. It will make builds inconsistent between projects.
Who's going to write a tool so that I can parse the build files? What if person X wants to do something one way, then person Y wants to do it another? Do you seriously want me to have to learn each and every way that a particular open source project is built? That's insanity waiting to happen.
I'm a big fan of XML based declarative build files; and requiring plugins to do specific tasks. Although, I'd like to see non-repeating elements go into attributes, as it would be easier to read.
I haven't got a huge amount of gradle experience, but if gradle, why not bash (if you're a Linux shop)??? Or better yet, make?Nov 17, 2014
Add a comment...