Huge +1 to the idea of investing in simplification and polish of the Gradle files before considering the migration complete.
1. build.gradle files should be as close to straight-line configuration as possible: - You should be able to understand a module's build easily, locally, without knowing Groovy - As little Groovy programming as possible, focused on providing well-defined utilities 2. Explicit > implicit, especially for config files - Ditto about being able to understand a module's build locally - Minimize globally inherited config, in favor of explicitly calling utilities - Passing current project to a utility is better than trying to make something the "closure" - If you are going to refer to an identifier, it should have an explicit point of origin (not strings smashed together in a loop) When in doubt, a little redundancy to improve readability is worth it in this context. Kenn On Mon, Apr 9, 2018 at 9:47 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi all, > > I did multiple gradle build since last week and I would like to share > one of my concern: it's about the communities. > > If I think our users won't see any change for them due to Gradle build > (I think that most of our users will still use Maven with artifacts > provided by Gradle), I'm more concerned by the dev community and the > contribution. > > Maven is well known and straight forward for a large part of potential > contributors. I think we have to keep in mind that we still have to grow > up our contributors community. > > Today, maybe I'm wrong, but I have the feeling that gradle build is not > straight forward (build.gradle includes build_rules.gradle, gathering > all taks all together). > > I would like to add a task in the gradle "migration" process: simplify > the gradle structure and files, and document this. > > I know we already have a Jira about the documentation part, but I would > like to "polish" and use a clean structure for the Gradle resources. As > already quickly discussed, I think that having one gradle file per tasks > in the .gradle directory would be helpful. > > The goal is really to simplify the contribution. > > Do you agree if I add a Jira about "Gradle polish" ? > Thoughts ? > > Regards > JB > > On 07/04/2018 04:52, Scott Wegner wrote: > > Here's an end-of-day update on migration work: > > > > * Snapshot unsigned dailies and signed release builds are working (!!). > > PR/5048 [1] merges changes from Luke's branch > > * python precommit failing... will investigate python precommit Monday > > * All Precommits are gradle only > > * All Postcommits except performance tests and Java_JDK_Versions_Test > > use gradle (after PR/5047 [2] merged) > > * Nightly snapshot release using gradle is ready; needs PR/5048 to be > > merged before switching > > * ValidatesRunner_Spark failing consistently; investigating > > > > Thanks for another productive day of hacking. I'll pick up again on > Monday. > > > > [1] https://github.com/apache/beam/pull/5048 > > [2] https://github.com/apache/beam/pull/5047 > > > > > > On Fri, Apr 6, 2018 at 11:24 AM Romain Manni-Bucau > > <[email protected] <mailto:[email protected]>> wrote: > > > > Why building a zip per runner which its stack and just pointing out > > on that zip and let beam lazy load the runner: > > > > --runner=LazyRunner --lazyRunnerDir=... --lazyRunnerOptions=... (or > > the fromSystemProperties() if it gets merged a day ;)) > > > > Le 6 avr. 2018 20:21, "Kenneth Knowles" <[email protected] > > <mailto:[email protected]>> a écrit : > > > > I'm working on finding a solution for launching the Nexmark > > suite with each runner. This doesn't have to be done via Gradle, > > but we anyhow need built artifacts that don't require user > > classpath intervention. > > > > It looks to me like the examples are also missing this - they > > have separate configuration e.g. sparkRunnerPreCommit but that > > is overspecified compared to a free-form launching of a main() > > program with a runner profile. > > > > On Fri, Apr 6, 2018 at 11:09 AM Lukasz Cwik <[email protected] > > <mailto:[email protected]>> wrote: > > > > Romain, are you talking about the profiles that exist as > > part of the archetype examples? > > > > If so, then those still exist and haven't been changed. If > > not, can you provide a link to the profile in a pom file to > > be clearer? > > > > On Fri, Apr 6, 2018 at 12:40 PM Romain Manni-Bucau > > <[email protected] <mailto:[email protected]>> > wrote: > > > > Hi Scott, > > > > is it right that 2 doesn't handle the hierachy anymore > > and that it doesn't handle profiles for runners as it is > > currently with maven? > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | LinkedIn > > <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > 2018-04-06 18:32 GMT+02:00 Scott Wegner > > <[email protected] <mailto:[email protected]>>: > > > > I wanted to start a thread to summarize the current > > state of Gradle migration. We've made lots of good > > progress so far this week. Here's the status from > > what I can tell-- please add or correct anything I > > missed: > > > > * Release artifacts can be built and published for > > Snapshot and officlal releases [1] > > * Gradle-generated releases have been validated with > > the the Apache Beam archetype generation quickstart; > > still needs additional validation. > > * Generated release pom files have correct project > > metadata [2] > > * The python pre-commits are now working in Gradle > [3] > > * Ismaël has started a collaborative doc of Gradle > > tips [4] as we all learn the new system-- please add > > your own. This will eventually feed into official > > documentation on the website. > > * Łukasz Gajowy is working on migrating performance > > testing framework [5] > > * Daniel is working on updating documentation to > > refer to Gradle instead of maven > > > > If I missed anything, please add it to this thread. > > > > The general roadmap we're working towards is: > > (a) Publish release artifacts with Gradle (SNAPSHOT > > and signed releases) > > (b) Postcommits migrated to Gradle > > (c) Migrate documentation from maven to Gradle > > (d) Migrate perfkit suites to use Gradle > > > > For those of you that are hacking: thanks for your > > help so far! Progress is being roughly tracked on > > the Kanban [6]; please make sure the issues assigned > > to you are up-to-date. Many of the changes are > > staged on lukecwik's local branch [7]; we'll work on > > merging them back soon. > > > > > > [1] > https://github.com/lukecwik/incubator-beam/pull/7 > > [2] > https://github.com/lukecwik/incubator-beam/pull/3 > > [3] https://github.com/apache/beam/pull/5032 > > [4] > > > https://docs.google.com/document/d/1wR56Jef3XIPwj4DFzQKznuGPM3JDfRDVkxzeDlbdVSQ/edit > > [5] https://github.com/apache/beam/pull/5003 > > [6] > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=242 > > > > [7] > > > https://github.com/lukecwik/incubator-beam/tree/gradle > > -- > > > > > > Got feedback? http://go/swegner-feedback > > > > > > -- > > > > > > Got feedback? http://go/swegner-feedback >
