drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edmon Begoli <ebeg...@gmail.com>
Subject Gradle?
Date Sun, 13 Sep 2015 15:56:28 GMT
Ted,

I will tell you my opinion, not some deeply researched engineered position.
Right now, I am looking into Gradle to be my primary build/release tool. I
am not 100% set on it, but I see plenty of benefits, main being
conciseness, configurabity, and robustness of the build process.
In the context of the Drill project, here are couple of things I could
recommend:

- you can still use the same POMs, so one can immediately use it without
breaking backward compatibility. You can go forever with POMs

- much smaller build definition file (very subjective here because I do not
like XML for human use)

- you can break up the build up into multiple independent tasks. I think
this would help with making tests more modular etc.

- continues execution after failures. This saves time a lot.

- much more expressive and feature-full task design and execution
   -- API automatic detection of build dependencies
   -- a complete DAG for dependencies - one task can depend on multiple
others, and any of the dependencies can be of any depth

- dry run feature - you can see what will compile without having to
actually build it

- it can support and produce multiple versions, supports multiple profiles,
etc.

There are many others to mention, but I just wanted to share these few that
could be of interest.

Edmon

On Sun, Sep 13, 2015 at 2:46 AM, Ted Dunning <ted.dunning@gmail.com
<javascript:_e(%7B%7D,'cvml','ted.dunning@gmail.com');>> wrote:

> Not particularly.
>
> Maven handles the needs so far pretty easily and has the considerable
> benefit of being bog standard.
>
> What benefit would you foresee with gradle?
>
>
>
>
> On Sat, Sep 12, 2015 at 9:02 PM, Edmon Begoli <ebegoli@gmail.com
> <javascript:_e(%7B%7D,'cvml','ebegoli@gmail.com');>> wrote:
>
> > Hey guys - has there been any consideration given to using Gradle in the
> > future instead of Maven?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message