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.

Reply via email to