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 [1], [2]. Should we incorporate them to Beam's confluence?
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. Łukasz [1] https://docs.google.com/document/d/1wR56Jef3XIPwj4DFzQKznuGPM3JDfRDVkxzeDlbdVSQ/edit?usp=sharing [2] https://docs.google.com/document/d/1EiTwEMD8FNhU4Ok6jthASpmK3-1hiAYzVTrdl8qBLrs/edit?usp=sharing wt., 9 paź 2018 o 10:25 Reuven Lax <re...@google.com> napisał(a): > 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). > > Reuven > > On Tue, Oct 9, 2018 at 1:04 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi guys, >> >> 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 Maven to >> Gradle. One of the key expected improvement was the time to build. >> We proposed to do a PoC to evaluate the impacts and improvements, but >> 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 provided >> by Gradle. >> 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 Gradle >> benefits. >> 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 doing to >> 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 too. The >> integration on IDE (especially IntelliJ) is not good enough right now. >> >> 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 code itself. >> >> So, obviously, the situation is not perfect, at least from a contributor >> perspective. >> >> 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 it makes >> such sense from a contributor perspective, as Maven is really well known >> from most of contributors (and easier to start with IMHO). >> 2. Back on Maven. That's clearly my preferred approach. IDE integration >> is better, Maven is well known from the contributors as already said. >> 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 project >> lifetime. >> >> Thoughts ? >> >> Regards >> JB >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
