Thanks for starting this thread.
I would go for 1. To all the problems that you described I'd add
improving documentation - there are still some places that have only
maven instructions (eg. word count examples). There already are some
docs that provide help , . Should we incorporate them to
I don't think 2 is the way to go. All the problems described above do
not seem to be unfixable (are the issues with the current Gradle setup
are impossible to fix?). We should focus on the fixes not on bringing
back maven and adapting it to current requirements.
FWIW, from my experience in working on contributions, I'm not affected
by the first three problems that you described. I rarely need to build
the whole project and I never had problems with daemon and
parallel builds. It is also easier for me to work with Gradle thanks to
its great DSL and composable tasks.
wt., 9 paź 2018 o 10:25 Reuven Lax <relax@xxxxxxxxxx
I'm not going to comment too much on most of these points (as I
think others can do so better). However I think that the effort
required to migrate back to Maven will actually be quite
significant. Much has been added to Beam (both to the codebase, and
to our Jenkins tooling, etc.) since we moved to Gradle, and none of
this has been added to Maven. I believe that going back and
migrating all of this to Maven will be difficult at this point.
I would vote for option 1. I believe that many of the current
issues are easily fixable. For example, requiring no-parallel I
believe is because some of our dependencies are incorrectly setup in
gradle files, and nobody has taken the time to track this down and
fix it (it was easier to just start setting that flag).
On Tue, Oct 9, 2018 at 1:04 AM Jean-Baptiste Onofré <jb@xxxxxxxxxxxx
I know that's a hot topic, but I have to bring this discussion
on the table.
Some months ago, we discussed about migrating our build from
Gradle. One of the key expected improvement was the time to build.
We proposed to do a PoC to evaluate the impacts and
this PoC was actually directly a migrate on master.
Now, I would like to bring facts here:
1. Build time
On my machine, the build time is roughly 1h15. It's pretty long, and
regarding what the build is doing, I don't see huge improvement
2. Build reliability
Even worse, most of the time, we need to use --no-parallel and
--no-daemon to have a reliable build (it's basically recommended for
release). It has an impact on build time, and we loose part of
3. Release and repositories
Even if couple of releases has been performed with Gradle, it's not
obvious to see improvements around artifacts handling. I got my
repository polluted twice (that's part of the trick Gradle is
speed up the build dealing around the repository).
4. IDE integration
We already had some comments on the mailing lists about the IDE
integration. Clearly, the situation is not good on that front
integration on IDE (especially IntelliJ) is not good enough
We are working hard to grow up the community, and from a contributor
perspective, our build system is not good today IMHO.
As a contributor, I resumed my work on some PRs, and I'm spending so
much time of the build, largely more than working on the PRs
So, obviously, the situation is not perfect, at least from a
The purpose of this thread is not again to have a bunch of replied
ending nowhere. I would like to be more "pushy" and let's try to be
concrete. So basically, we only have two options:
1. Improve the build, working hard on Gradle front. Not sure if
such sense from a contributor perspective, as Maven is really
from most of contributors (and easier to start with IMHO).
2. Back on Maven. That's clearly my preferred approach. IDE
is better, Maven is well known from the contributors as already
The effort is not so huge. We tried to use Gradle, we don't have the
expected results now, that's not a problem, it's part of a
Talend - http://www.talend.com