5 ms·

Maven’s approach is a lost cause: you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahaha

by eecc 9y ago

Maven’s approach is a lost cause: you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) or you breakout to some exec plugin and give up on platform agnostic builds. Sure, it’s an unforgiving ambition and many other systems fell trying, but it was their choice. With Gradle the blame falls squarely at the feet of plugins, and you’re on your own (which has always been the case anyway)

lmm 9y ago
> you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) I find all the cases can be coerced, and it's not even hard. Some users seem to insist on customization for its own sake, "oh I absolutely must call my source folder source rather than src", but Maven does the right thing by ignoring those users, with the result that you can pick up any project that uses Maven and be immediately productive.
- vbezhenar 9y ago
  I'm not sure what's your point, but Maven allows to change source folder very easily. Maven has sensible defaults, that's right.
- Macha 9y ago
  The case I remember was a couple of years ago. We had a test runner for our JS code that was delivered by our Java webapp. Part of that configuration was the list of flags to a maven plugin. The issue was that we had two orthogonal configuration options that affected the list of flags. Initially, it used HTMLUnit and didn't record coverage statistics. We wanted to record coverage, and also switch to PhantomJS (when it was new) over HTMLUnit. Our test times were as follows: PhantomJS - 1 min PhantomJS + Coverage - 5 min HTMLUnit - 10 min HTMLUnit + Coverage - 25min Coverage required one set of additional flags, PhantomJS required another. But we could only replace the test runner string, not add to it. We couldn't drop HTMLUnit altogether, as our company mandated CI system would not make it easy to install PhantomJS. And tests were still new to many team members so if we defaulted coverage on, nobody would run it with those times. So ideally we'd have mvn test -Pphantomjs -Pcoverage if we wanted phantom with coverage. But actually we had to do mvn test -P{phantomCoverage,htmlUnitCoverage,phantomNoCoverage,htmlUJnitNoCoverage} which meant copy pasting a substantial chunk of our pom file 4 times to change two lines of it, rather than a base case with two overrides.
  - lmm 9y ago
    Ok, good example of the tradeoff maven makes. My view is: it's worth making that kind of inherently complex case complex for the sake of the comprehensibility advantage that all projects gain from having the entire test runner string in one fixed place where a reader can look for it. Some test plugins do provide a separate "extraArgs"-type config that you can use for that kind of case, but I'm not convinced that it's a good idea.

by eecc 9y ago

lmm 9y ago

> you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) I find all the cases can be coerced, and it's not even hard. Some users seem to insist on customization for its own sake, "oh I absolutely must call my source folder source rather than src", but Maven does the right thing by ignoring those users, with the result that you can pick up any project that uses Maven and be immediately productive.

vbezhenar 9y ago
I'm not sure what's your point, but Maven allows to change source folder very easily. Maven has sensible defaults, that's right.
Macha 9y ago
The case I remember was a couple of years ago. We had a test runner for our JS code that was delivered by our Java webapp. Part of that configuration was the list of flags to a maven plugin. The issue was that we had two orthogonal configuration options that affected the list of flags. Initially, it used HTMLUnit and didn't record coverage statistics. We wanted to record coverage, and also switch to PhantomJS (when it was new) over HTMLUnit. Our test times were as follows: PhantomJS - 1 min PhantomJS + Coverage - 5 min HTMLUnit - 10 min HTMLUnit + Coverage - 25min Coverage required one set of additional flags, PhantomJS required another. But we could only replace the test runner string, not add to it. We couldn't drop HTMLUnit altogether, as our company mandated CI system would not make it easy to install PhantomJS. And tests were still new to many team members so if we defaulted coverage on, nobody would run it with those times. So ideally we'd have mvn test -Pphantomjs -Pcoverage if we wanted phantom with coverage. But actually we had to do mvn test -P{phantomCoverage,htmlUnitCoverage,phantomNoCoverage,htmlUJnitNoCoverage} which meant copy pasting a substantial chunk of our pom file 4 times to change two lines of it, rather than a base case with two overrides.
- lmm 9y ago
  Ok, good example of the tradeoff maven makes. My view is: it's worth making that kind of inherently complex case complex for the sake of the comprehensibility advantage that all projects gain from having the entire test runner string in one fixed place where a reader can look for it. Some test plugins do provide a separate "extraArgs"-type config that you can use for that kind of case, but I'm not convinced that it's a good idea.