On Sep 10, 2012, at 4:15 AM, Graham Leggett <[email protected]> wrote:
> On 9 Sep 2012, at 22:20, "KARR, DAVID" <[email protected]> wrote: > >> One of the disadvantages of Gradle is the same as Ant, which is that it's >> very easy to have two people do similar things in a completely different way. > > This to me is the fatal flaw in ant and all tools like it. Ant allows the > developer to do whatever they like, and so they do, unnecessarily different > to everyone else, and this difference must be debugged, documented and > learned, over and over again, wasting countless hours and money. > > In contrast, Maven represents discipline. > > To understand maven one first has to understand discipline in software > engineering, why there is no value in solving a solved problem in a way that > is different but no better than solutions that have gone before. Why the best > documentation is simply no documentation at all. Why the gift of a repeatable > build is priceless to the person who has to fix a bug under stressful > conditions. Well said by Ron and Graham. With the knowledge as the person that wrote the "associated Maven build" (shameless plug ;) and without disclosing anything, I think you can see based on it's dependencies that it's not going away anytime soon. There was a lot of resistance to it in the first place, to the point that I was seriously asked a few times why the build couldn't be ported to Ant. What that says to me is there is a lot of organizational inertia around not doing the same thing multiple ways. In interviewing stakeholders, nobody was attached to Ant, they just knew it's warts and how to get around. It was a sunk cost. Totally reasonable. Gradle not only allows the same thing to be done multiple ways (like Ant), but now you would be introducing all of Gradle's multiple ways in it's own different way. You'll have one paradigm that is "hard" but can't and won't be removed, one that is almost universally deprecated (I can't remember the last time I've seen a new project using it), and another that is some hybrid of the two, but with completely different syntactic sugar. Given the resistance to adding one new build tool, adding a second for a total of three doesn't sound likely. Also do not forget about plugin support necessary for target environments. I did do the thought experiment at the time why the build could (or should) not be rewritten in Ant (welcome to the world of being a good contractor!), and the final reason Ant couldn't be used was target product plugin support for Ant wasn't there. If you dig into the plugin context that is available when a plugin runs, one wouldn't seriously attempt to run Maven plugins in an Ant build. I theoretically could have ported the plugin(s) to Ant task(s), but one key vendor plugin was proprietary. This same problems will haunt you in Gradle until all vendors have equal support for Gradle as they do for Maven. While I think I only wrote one plugin for that build, such internal plugins can be used in builds across the company. This is another reason to standardize on a single build environment. This isn't to say that you won't need to do some plugin work to get your new build in robust working order. When I did the (now apparently missing) POC of it, I remember that there was some issues that were not solvable with five minutes of Maven foo (and why I stopped working on it). But it wasn't weeks of work either. HTH, Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
