[DISCUSS] Move away from Apache Maven as build tool

[Lukasz Cwik <lc...@google.com.INVALID>]

I wanted to make this thread more visible. This discussion stems from Ken's
thread about Jenkins pre/post commit issues[1].

I did some investigation as for ways to improve the quality of the signal
from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
had limited success but everything I felt like I was doing was just
patching symptoms of the problem which is that our build is just too slow.
For example, we keep adding all these profiles to Maven or tuning how a
plugin runs to eek out a small decrease in build time. I believe swapping
away from Apache Maven to a build tool which only builds the things which
have changed in a PR would be the best approach.

I would suggest that we migrate to Gradle as our build tool. I am
suggesting Gradle because:
* It is used in lots of open source projects and has a very large community
behind it.
* It has better support for building languages other then Java
(PyGradle[2], GoGradle[3], ...)
* Its incremental build support works and only builds things that changed
through the use of a build cache. Even without the build cache (or for
clean builds), it is much faster.
* Apache Infra already has Gradle v4.x installed on the Jenkins machines.

Any alternatives that should be considered or should we stick with Apache
Maven?

1:
https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d357984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
2: https://github.com/linkedin/pygradle
3: https://github.com/gogradle/gogradle

Re: [DISCUSS] Move away from Apache Maven as build tool

[Henning Rohde <he...@google.com.INVALID>]

+1 to the initiative. It would great to have better support for Go and
Docker container images. The current Go maven integration in particular is
clunky [1], but I'll have to look into the details of the alternatives to
see if they are better.

Henning

[1] https://github.com/apache/beam/blob/master/sdks/go/BUILD.md

On Mon, Oct 30, 2017 at 10:27 AM, Kenneth Knowles <kl...@google.com.invalid>
wrote:

> I also support exploring a move away from Apache Maven for orchestrating
> our build.
>
> For a single-module project, I still think it can be a good build tool, and
> we could still use it for this sort of thing, but I think we are reaching a
> multi-module scale where it does not work well. Almost all of our jobs
> build things that are not needed and run tests that are redundant, and it
> is not easy to do better, even with a sequence of maven commands.
>
> I'd like to lay out what we hope for from a tool. Here's a start:
>
> General:
>
>  - Dependency-driven build so devs working on one thing build & test only
> what is needed
>  - Supports orchestration across Protobuf, Java, Python, Go, Docker images
>  - Meets devs where they are, letting folks in one language use familiar
> tools
>  - Caching across builds as much as possible
>  - Easily extensible for when it doesn't have the feature we need (writing
> a maven plugin is too much, using maven-exec-plugin is too crufty)
>  - Preferably a declarative configuration language
>
> Java needs beyond the basics, which could be executed by the orchestrator
> or my module-local mvn builds, etc.
>
>  - Pulling deps from maven central and alternate repos
>  - Findbugs
>  - RAT
>  - Dependency rule enforcement
>  - IWYU (Include What You Use)
>  - Multiple Java versions in same project
>  - ASF release workflow
>
> I probably missed some must-haves or nice-to-haves. I'd love to compile
> thoughts on other languages' needs.
>
> Based on these, another project I would consider is Bazel. We could very
> easily use it to orchestrate, but use Maven (or Gradle!) on the leaves. I
> also think that Gradle is also more focused on the JVM ecosystem, so it is
> not quite as neutral as Bazel, and uses Groovy which is a bit more esoteric
> than Python for writing Bazel rules.
>
> Kenn
>
> On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
> wrote:
>
> > I wanted to make this thread more visible. This discussion stems from
> Ken's
> > thread about Jenkins pre/post commit issues[1].
> >
> > I did some investigation as for ways to improve the quality of the signal
> > from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> > had limited success but everything I felt like I was doing was just
> > patching symptoms of the problem which is that our build is just too
> slow.
> > For example, we keep adding all these profiles to Maven or tuning how a
> > plugin runs to eek out a small decrease in build time. I believe swapping
> > away from Apache Maven to a build tool which only builds the things which
> > have changed in a PR would be the best approach.
> >
> > I would suggest that we migrate to Gradle as our build tool. I am
> > suggesting Gradle because:
> > * It is used in lots of open source projects and has a very large
> community
> > behind it.
> > * It has better support for building languages other then Java
> > (PyGradle[2], GoGradle[3], ...)
> > * Its incremental build support works and only builds things that changed
> > through the use of a build cache. Even without the build cache (or for
> > clean builds), it is much faster.
> > * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
> >
> > Any alternatives that should be considered or should we stick with Apache
> > Maven?
> >
> > 1:
> > https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> > 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> > 2: https://github.com/linkedin/pygradle
> > 3: https://github.com/gogradle/gogradle
> >
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Reuven Lax <re...@google.com.INVALID>]

I will add one more thing I think we all want from a build tool - good IDE
integration with IntelliJ and Eclipse.

On Mon, Oct 30, 2017 at 10:27 AM, Kenneth Knowles <kl...@google.com.invalid>
wrote:

> I also support exploring a move away from Apache Maven for orchestrating
> our build.
>
> For a single-module project, I still think it can be a good build tool, and
> we could still use it for this sort of thing, but I think we are reaching a
> multi-module scale where it does not work well. Almost all of our jobs
> build things that are not needed and run tests that are redundant, and it
> is not easy to do better, even with a sequence of maven commands.
>
> I'd like to lay out what we hope for from a tool. Here's a start:
>
> General:
>
>  - Dependency-driven build so devs working on one thing build & test only
> what is needed
>  - Supports orchestration across Protobuf, Java, Python, Go, Docker images
>  - Meets devs where they are, letting folks in one language use familiar
> tools
>  - Caching across builds as much as possible
>  - Easily extensible for when it doesn't have the feature we need (writing
> a maven plugin is too much, using maven-exec-plugin is too crufty)
>  - Preferably a declarative configuration language
>
> Java needs beyond the basics, which could be executed by the orchestrator
> or my module-local mvn builds, etc.
>
>  - Pulling deps from maven central and alternate repos
>  - Findbugs
>  - RAT
>  - Dependency rule enforcement
>  - IWYU (Include What You Use)
>  - Multiple Java versions in same project
>  - ASF release workflow
>
> I probably missed some must-haves or nice-to-haves. I'd love to compile
> thoughts on other languages' needs.
>
> Based on these, another project I would consider is Bazel. We could very
> easily use it to orchestrate, but use Maven (or Gradle!) on the leaves. I
> also think that Gradle is also more focused on the JVM ecosystem, so it is
> not quite as neutral as Bazel, and uses Groovy which is a bit more esoteric
> than Python for writing Bazel rules.
>
> Kenn
>
> On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
> wrote:
>
> > I wanted to make this thread more visible. This discussion stems from
> Ken's
> > thread about Jenkins pre/post commit issues[1].
> >
> > I did some investigation as for ways to improve the quality of the signal
> > from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> > had limited success but everything I felt like I was doing was just
> > patching symptoms of the problem which is that our build is just too
> slow.
> > For example, we keep adding all these profiles to Maven or tuning how a
> > plugin runs to eek out a small decrease in build time. I believe swapping
> > away from Apache Maven to a build tool which only builds the things which
> > have changed in a PR would be the best approach.
> >
> > I would suggest that we migrate to Gradle as our build tool. I am
> > suggesting Gradle because:
> > * It is used in lots of open source projects and has a very large
> community
> > behind it.
> > * It has better support for building languages other then Java
> > (PyGradle[2], GoGradle[3], ...)
> > * Its incremental build support works and only builds things that changed
> > through the use of a build cache. Even without the build cache (or for
> > clean builds), it is much faster.
> > * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
> >
> > Any alternatives that should be considered or should we stick with Apache
> > Maven?
> >
> > 1:
> > https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> > 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> > 2: https://github.com/linkedin/pygradle
> > 3: https://github.com/gogradle/gogradle
> >
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Reuven Lax <re...@google.com.INVALID>]

I wonder if we could prototype both Bazel and Gradle to do a better
comparison (and also to compare the results with our current Maven build).

On Mon, Oct 30, 2017 at 10:32 AM, Ben Chambers <bchambers@google.com.invalid
> wrote:

> I think both Gradle and Bazel are worth exploring. Gradle is definitely
> more common in the wild, but Bazel may be a better fit for the large
> mixture of languages being developed in one codebase within Beam. It might
> be helpful for us to list what functionality we want from such a tool, and
> then have someone who is interested in this dig in a bit and let us know
> more details how well Gradle or Bazel would fit our needs.
>
> On Mon, Oct 30, 2017 at 10:27 AM Kenneth Knowles <kl...@google.com.invalid>
> wrote:
>
> > I also support exploring a move away from Apache Maven for orchestrating
> > our build.
> >
> > For a single-module project, I still think it can be a good build tool,
> and
> > we could still use it for this sort of thing, but I think we are
> reaching a
> > multi-module scale where it does not work well. Almost all of our jobs
> > build things that are not needed and run tests that are redundant, and it
> > is not easy to do better, even with a sequence of maven commands.
> >
> > I'd like to lay out what we hope for from a tool. Here's a start:
> >
> > General:
> >
> >  - Dependency-driven build so devs working on one thing build & test only
> > what is needed
> >  - Supports orchestration across Protobuf, Java, Python, Go, Docker
> images
> >  - Meets devs where they are, letting folks in one language use familiar
> > tools
> >  - Caching across builds as much as possible
> >  - Easily extensible for when it doesn't have the feature we need
> (writing
> > a maven plugin is too much, using maven-exec-plugin is too crufty)
> >  - Preferably a declarative configuration language
> >
> > Java needs beyond the basics, which could be executed by the orchestrator
> > or my module-local mvn builds, etc.
> >
> >  - Pulling deps from maven central and alternate repos
> >  - Findbugs
> >  - RAT
> >  - Dependency rule enforcement
> >  - IWYU (Include What You Use)
> >  - Multiple Java versions in same project
> >  - ASF release workflow
> >
> > I probably missed some must-haves or nice-to-haves. I'd love to compile
> > thoughts on other languages' needs.
> >
> > Based on these, another project I would consider is Bazel. We could very
> > easily use it to orchestrate, but use Maven (or Gradle!) on the leaves. I
> > also think that Gradle is also more focused on the JVM ecosystem, so it
> is
> > not quite as neutral as Bazel, and uses Groovy which is a bit more
> esoteric
> > than Python for writing Bazel rules.
> >
> > Kenn
> >
> > On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
> > wrote:
> >
> > > I wanted to make this thread more visible. This discussion stems from
> > Ken's
> > > thread about Jenkins pre/post commit issues[1].
> > >
> > > I did some investigation as for ways to improve the quality of the
> signal
> > > from Jenkins by trying to modify the Jenkins jobs spawned from Groovy.
> I
> > > had limited success but everything I felt like I was doing was just
> > > patching symptoms of the problem which is that our build is just too
> > slow.
> > > For example, we keep adding all these profiles to Maven or tuning how a
> > > plugin runs to eek out a small decrease in build time. I believe
> swapping
> > > away from Apache Maven to a build tool which only builds the things
> which
> > > have changed in a PR would be the best approach.
> > >
> > > I would suggest that we migrate to Gradle as our build tool. I am
> > > suggesting Gradle because:
> > > * It is used in lots of open source projects and has a very large
> > community
> > > behind it.
> > > * It has better support for building languages other then Java
> > > (PyGradle[2], GoGradle[3], ...)
> > > * Its incremental build support works and only builds things that
> changed
> > > through the use of a build cache. Even without the build cache (or for
> > > clean builds), it is much faster.
> > > * Apache Infra already has Gradle v4.x installed on the Jenkins
> machines.
> > >
> > > Any alternatives that should be considered or should we stick with
> Apache
> > > Maven?
> > >
> > > 1:
> > > https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> > > 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> > > 2: https://github.com/linkedin/pygradle
> > > 3: https://github.com/gogradle/gogradle
> > >
> >
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Ben Chambers <bc...@google.com.INVALID>]

I think both Gradle and Bazel are worth exploring. Gradle is definitely
more common in the wild, but Bazel may be a better fit for the large
mixture of languages being developed in one codebase within Beam. It might
be helpful for us to list what functionality we want from such a tool, and
then have someone who is interested in this dig in a bit and let us know
more details how well Gradle or Bazel would fit our needs.

On Mon, Oct 30, 2017 at 10:27 AM Kenneth Knowles <kl...@google.com.invalid>
wrote:

> I also support exploring a move away from Apache Maven for orchestrating
> our build.
>
> For a single-module project, I still think it can be a good build tool, and
> we could still use it for this sort of thing, but I think we are reaching a
> multi-module scale where it does not work well. Almost all of our jobs
> build things that are not needed and run tests that are redundant, and it
> is not easy to do better, even with a sequence of maven commands.
>
> I'd like to lay out what we hope for from a tool. Here's a start:
>
> General:
>
>  - Dependency-driven build so devs working on one thing build & test only
> what is needed
>  - Supports orchestration across Protobuf, Java, Python, Go, Docker images
>  - Meets devs where they are, letting folks in one language use familiar
> tools
>  - Caching across builds as much as possible
>  - Easily extensible for when it doesn't have the feature we need (writing
> a maven plugin is too much, using maven-exec-plugin is too crufty)
>  - Preferably a declarative configuration language
>
> Java needs beyond the basics, which could be executed by the orchestrator
> or my module-local mvn builds, etc.
>
>  - Pulling deps from maven central and alternate repos
>  - Findbugs
>  - RAT
>  - Dependency rule enforcement
>  - IWYU (Include What You Use)
>  - Multiple Java versions in same project
>  - ASF release workflow
>
> I probably missed some must-haves or nice-to-haves. I'd love to compile
> thoughts on other languages' needs.
>
> Based on these, another project I would consider is Bazel. We could very
> easily use it to orchestrate, but use Maven (or Gradle!) on the leaves. I
> also think that Gradle is also more focused on the JVM ecosystem, so it is
> not quite as neutral as Bazel, and uses Groovy which is a bit more esoteric
> than Python for writing Bazel rules.
>
> Kenn
>
> On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
> wrote:
>
> > I wanted to make this thread more visible. This discussion stems from
> Ken's
> > thread about Jenkins pre/post commit issues[1].
> >
> > I did some investigation as for ways to improve the quality of the signal
> > from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> > had limited success but everything I felt like I was doing was just
> > patching symptoms of the problem which is that our build is just too
> slow.
> > For example, we keep adding all these profiles to Maven or tuning how a
> > plugin runs to eek out a small decrease in build time. I believe swapping
> > away from Apache Maven to a build tool which only builds the things which
> > have changed in a PR would be the best approach.
> >
> > I would suggest that we migrate to Gradle as our build tool. I am
> > suggesting Gradle because:
> > * It is used in lots of open source projects and has a very large
> community
> > behind it.
> > * It has better support for building languages other then Java
> > (PyGradle[2], GoGradle[3], ...)
> > * Its incremental build support works and only builds things that changed
> > through the use of a build cache. Even without the build cache (or for
> > clean builds), it is much faster.
> > * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
> >
> > Any alternatives that should be considered or should we stick with Apache
> > Maven?
> >
> > 1:
> > https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> > 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> > 2: https://github.com/linkedin/pygradle
> > 3: https://github.com/gogradle/gogradle
> >
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Kenneth Knowles <kl...@google.com.INVALID>]

I also support exploring a move away from Apache Maven for orchestrating
our build.

For a single-module project, I still think it can be a good build tool, and
we could still use it for this sort of thing, but I think we are reaching a
multi-module scale where it does not work well. Almost all of our jobs
build things that are not needed and run tests that are redundant, and it
is not easy to do better, even with a sequence of maven commands.

I'd like to lay out what we hope for from a tool. Here's a start:

General:

 - Dependency-driven build so devs working on one thing build & test only
what is needed
 - Supports orchestration across Protobuf, Java, Python, Go, Docker images
 - Meets devs where they are, letting folks in one language use familiar
tools
 - Caching across builds as much as possible
 - Easily extensible for when it doesn't have the feature we need (writing
a maven plugin is too much, using maven-exec-plugin is too crufty)
 - Preferably a declarative configuration language

Java needs beyond the basics, which could be executed by the orchestrator
or my module-local mvn builds, etc.

 - Pulling deps from maven central and alternate repos
 - Findbugs
 - RAT
 - Dependency rule enforcement
 - IWYU (Include What You Use)
 - Multiple Java versions in same project
 - ASF release workflow

I probably missed some must-haves or nice-to-haves. I'd love to compile
thoughts on other languages' needs.

Based on these, another project I would consider is Bazel. We could very
easily use it to orchestrate, but use Maven (or Gradle!) on the leaves. I
also think that Gradle is also more focused on the JVM ecosystem, so it is
not quite as neutral as Bazel, and uses Groovy which is a bit more esoteric
than Python for writing Bazel rules.

Kenn

On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
wrote:

> I wanted to make this thread more visible. This discussion stems from Ken's
> thread about Jenkins pre/post commit issues[1].
>
> I did some investigation as for ways to improve the quality of the signal
> from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> had limited success but everything I felt like I was doing was just
> patching symptoms of the problem which is that our build is just too slow.
> For example, we keep adding all these profiles to Maven or tuning how a
> plugin runs to eek out a small decrease in build time. I believe swapping
> away from Apache Maven to a build tool which only builds the things which
> have changed in a PR would be the best approach.
>
> I would suggest that we migrate to Gradle as our build tool. I am
> suggesting Gradle because:
> * It is used in lots of open source projects and has a very large community
> behind it.
> * It has better support for building languages other then Java
> (PyGradle[2], GoGradle[3], ...)
> * Its incremental build support works and only builds things that changed
> through the use of a build cache. Even without the build cache (or for
> clean builds), it is much faster.
> * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
>
> Any alternatives that should be considered or should we stick with Apache
> Maven?
>
> 1:
> https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> 2: https://github.com/linkedin/pygradle
> 3: https://github.com/gogradle/gogradle
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Eugene Kirpichov <ki...@google.com.INVALID>]

This seems like a very good idea. With the effective complete lack of
incremental builds in Maven, it's frustrating to routinely spend several
minutes re-verifying a PR after fixing a checkstyle warning in an extension
module.

Another non-Apache alternative could be Bazel, which is even faster and
better at incremental builds [1], but the performance difference is not
*that* big and anyway both leave Maven far behind; and Gradle definitely
has better integration with other parts of the Apache ecosystem and is more
familiar to the community. So +1.

[1] https://www.pgrs.net/2015/09/01/migrating-from-gradle-to-bazel/

On Mon, Oct 30, 2017 at 9:37 AM Lukasz Cwik <lc...@google.com.invalid>
wrote:

> I wanted to make this thread more visible. This discussion stems from Ken's
> thread about Jenkins pre/post commit issues[1].
>
> I did some investigation as for ways to improve the quality of the signal
> from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> had limited success but everything I felt like I was doing was just
> patching symptoms of the problem which is that our build is just too slow.
> For example, we keep adding all these profiles to Maven or tuning how a
> plugin runs to eek out a small decrease in build time. I believe swapping
> away from Apache Maven to a build tool which only builds the things which
> have changed in a PR would be the best approach.
>
> I would suggest that we migrate to Gradle as our build tool. I am
> suggesting Gradle because:
> * It is used in lots of open source projects and has a very large community
> behind it.
> * It has better support for building languages other then Java
> (PyGradle[2], GoGradle[3], ...)
> * Its incremental build support works and only builds things that changed
> through the use of a build cache. Even without the build cache (or for
> clean builds), it is much faster.
> * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
>
> Any alternatives that should be considered or should we stick with Apache
> Maven?
>
> 1:
>
> https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d357984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> 2: https://github.com/linkedin/pygradle
> 3: https://github.com/gogradle/gogradle
>

Re: [DISCUSS] Move away from Apache Maven as build tool

[Reuven Lax <re...@google.com.INVALID>]

If we're looking at other build options, I think we should also consider
Bazel. Some advantages I see of Bazel over Gradle:

Gradle is reportedly much slower than Bazel. I haven't measured this
myself, but there are many user reports of slow builds, memory leaks, etc.

Bazel's build language is based on Python, which more people are familiar
with than Groovy (which Gradle uses)

Bazel has build rules for building Docker images, which will be very useful
in the multi-language world.

Of course Gradle has been around longer, and as Luke mentioned is already
installed on the Jenkins machines.

In general, while Maven has done well for Beam (and prior to Beam for
Dataflow) for quite some time, Maven is primarily a Java build tool. As
Beam becomes a cross-language platform, I think we're seeing Maven become
more of an awkward fit. Our cross language "rules" are essentially just
shell scripts, where other build systems can natively manage those rules.
We're going to start wanting dependencies between components in different
languages, which is going to be difficult to do in Maven.

I don't think Maven can completely go away, we still depend on Maven
plugins for a number of things (RAT, FindBugs, etc.). Also an initial
approach might be to continue using Maven to build Java (for now at least),
but to use one of these other build systems to orchestrate the build across
all languages.

Reuven

On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <lc...@google.com.invalid>
wrote:

> I wanted to make this thread more visible. This discussion stems from Ken's
> thread about Jenkins pre/post commit issues[1].
>
> I did some investigation as for ways to improve the quality of the signal
> from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I
> had limited success but everything I felt like I was doing was just
> patching symptoms of the problem which is that our build is just too slow.
> For example, we keep adding all these profiles to Maven or tuning how a
> plugin runs to eek out a small decrease in build time. I believe swapping
> away from Apache Maven to a build tool which only builds the things which
> have changed in a PR would be the best approach.
>
> I would suggest that we migrate to Gradle as our build tool. I am
> suggesting Gradle because:
> * It is used in lots of open source projects and has a very large community
> behind it.
> * It has better support for building languages other then Java
> (PyGradle[2], GoGradle[3], ...)
> * Its incremental build support works and only builds things that changed
> through the use of a build cache. Even without the build cache (or for
> clean builds), it is much faster.
> * Apache Infra already has Gradle v4.x installed on the Jenkins machines.
>
> Any alternatives that should be considered or should we stick with Apache
> Maven?
>
> 1:
> https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3
> 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E
> 2: https://github.com/linkedin/pygradle
> 3: https://github.com/gogradle/gogradle
>