Finally got to write down my gripes with Maven, with a catchy title ;-)
46 plus ones
Shared publicly•View activity
View 31 previous comments
- What happens is that the immutable model is later translated to the mutable one. Thus it remains possible for plugins to continue as normal. However the polyglot-scala model is immutable and I just wanted to highlight that.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
- Re. Mutable model during the execution phase, yes I'd agree having an immutable runtime model as per, say, sbt is great. However I don't think that makes Maven broken, just not perfect.
Lets not forget that Maven's primary goal is project comprehension. It isn't about allowing you to personally express your build aka ant, make etc. Maven is there so that others can understand what is going on in your project. Show me another build tool primarily designed with project comprehension for others as its goal. Tesla-polyglot-scala is there to correct the expression of that incredibly important project comprehension goal.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