Don't forget the point about community and contributor perspective. If it can be fixed just by documentation, that's great.
Regards JB Le 9 oct. 2018 à 12:50, à 12:50, "Łukasz Gajowy" <[email protected]> a écrit: >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 <[email protected]> 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é <[email protected]> >> 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é >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>
