OK. To explain some of the reasons that moving has little force, here are some answers in-line.
The summary is that I think that you are claiming that gradle offers a combination of readability, expressiveness and flexibility. My thought in response is that the readability difference is probably real, but not very important, that the expressiveness and flexibility are actually mis-features, at least potentially. Mostly, though, I feel like this is in the intersection of "ain't broke" and "religious" categories. On Sun, Sep 13, 2015 at 8:56 AM, Edmon Begoli <ebeg...@gmail.com> wrote: > - you can still use the same POMs, so one can immediately use it without > breaking backward compatibility. You can go forever with POMs > Nice. > - much smaller build definition file (very subjective here because I do not > like XML for human use) > I hear you here, but this has much less impact any more than it used to. This has happened because tools like IDEA do most of the editing of the pom's and they also assist in reading them by folding the text. As much as XML is a pain to work with manually, once the task becomes semi-automated, it really doesn't matter that much. > - you can break up the build up into multiple independent tasks. I think > this would help with making tests more modular etc. > Not sure how this is different from what we have now. I am very dubious of having too much more flexibility since much of the value in a build system is extreme standardization of the life-cycle. > - continues execution after failures. This saves time a lot. > Yes. It can be helpful. On the other hand, how often does the build fail? My gut feeling is that modern builds fail far less than builds used to fail. This is probably partly due to continuous integration and partly due to more standardization in the various build tasks so I don't have to worry about where things go nor do I have to worry that somebody has not implemented a standard build step poorly in some ant or make build script somewhere. > - much more expressive and feature-full task design and execution > I am actually somewhat of an opponent of expressiveness in builds. I prefer that they be bog standard and boring. Creativity belongs elsewhere. > -- API automatic detection of build dependencies > Maven does this (at least with IDEA). > -- a complete DAG for dependencies - one task can depend on multiple > others, and any of the dependencies can be of any depth > Maven has this. > - dry run feature - you can see what will compile without having to > actually build it > Maven has this. > - it can support and produce multiple versions, supports multiple profiles, > etc. > Maven has this.