Ah, I did not. Thanks Romain. I tried it again, restarting in between, and still had no differences. Since it seems like there's no reason not to use "Gradle Test Runner", I'll mention it in the contributor's guide.
On Thu, Apr 12, 2018 at 10:31 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > @Daniel: did you restart in between? Otherwise it does nothing. One > launches JunitCoreRunner from idea and the other a gradle command. > > Le 12 avr. 2018 19:24, "Daniel Oliveira" <danolive...@google.com> a > écrit : > >> I think it depends on what exactly switching to "Gradle Test Runner" from >> "Platform Test Runner" does. I tried it out on my machine and they seem to >> act identically to each other. The IntelliJ documentation says it >> determines what API to use to run the tests >> <https://www.jetbrains.com/help/idea/runner.html>, so maybe it's >> usefulness depends on the user's machine, in which case a note about that >> would be useful. Something like: "If your IDE has trouble running tests via >> IDEA shortcuts, try the following steps: [...]" >> >> On Thu, Apr 12, 2018 at 3:29 AM Alexey Romanenko < >> aromanenko....@gmail.com> wrote: >> >>> Daniel, actually I did run it with default IDEA JUnit test runner. Then, >>> in “Settings > Build, Execution, Deployment > Build Tools > Gradle > >>> Runner" I selected “Gradle Test Runner” in “Run tests using” selectbox and >>> it works ok when I run my tests with IDEA shortcuts. So, probably, we >>> should add this details on https://beam.apache.org/contribute/intellij/ >>> too. >>> What do you think? >>> >>> WBR, >>> Alexey >>> >>> On 11 Apr 2018, at 21:17, Daniel Oliveira <danolive...@google.com> >>> wrote: >>> >>> Alexey, are you referring to tests run with "./gradlew >>> :beam-runners-direct-java:needsRunnerTests"? That command works fine for me >>> in both versions of IDEA, but I believe the same tests fail if you run them >>> directly through "./gradlew test". >>> >>> However, I am having issues with a bunch of validatesRunner tests, >>> mostly be caused by >>> :beam-runners-google-cloud-dataflow-java:validatesRunner. Not sure if it's >>> because of a code change or a gradle config, I'll keep looking into it. >>> >>> On Wed, Apr 11, 2018 at 11:01 AM Romain Manni-Bucau < >>> rmannibu...@gmail.com> wrote: >>> >>>> I got tests running rrconfiguring gradle (which was setup for another >>>> project but seems beam didnt like it) but latency is still "high" using >>>> gradle runner for tests (like Etienne said ~3s on an i7 with 16G vs a few >>>> ms with default idea test runner, would be great to solve that). >>>> >>>> I also find the integration quite fishy cause configurations are >>>> customs so idea is kind of forced to propose your modukes 3 times at least >>>> when you select the classpath (x_test being generally the working one). >>>> >>>> Also the false positive you get if you forget a cleanX is a bit >>>> annoying, maybe we should force a clean for test or at least when there is >>>> a --tests to avoid gradle to not run it cause there is no diff. >>>> >>>> So it works but dev productivity is reduced a lot and it became slow >>>> enough to think if you should do a contribution or not - at least for me. >>>> >>>> Le 11 avr. 2018 19:37, "Alexey Romanenko" <aromanenko....@gmail.com> a >>>> écrit : >>>> >>>>> I’ve managed to import a project as it’s described in documentation >>>>> (starting from empty project) using Idea 2018 and run unit tests >>>>> successfully. >>>>> For some reasons, tests, that use DirectRunner to run a pipeline, were >>>>> failed. >>>>> >>>>> WBR, >>>>> Alexey >>>>> >>>>> On 11 Apr 2018, at 19:01, Daniel Oliveira <danolive...@google.com> >>>>> wrote: >>>>> >>>>> Hi everyone, I was the one who initially wrote the PR with Idea >>>>> instructions <https://github.com/apache/beam-site/pull/414>. I was >>>>> using 2017.3 as well while writing it so all the instructions were tested >>>>> on that version. I'll try testing the instructions on 2018 to see if I can >>>>> reproduce the issues people are having. >>>>> >>>>> On Wed, Apr 11, 2018 at 9:51 AM Lukasz Cwik <lc...@google.com> wrote: >>>>> >>>>>> I use 2017.3 and it has been reliable for me. I haven't tried 2018 >>>>>> yet. >>>>>> >>>>>> On Wed, Apr 11, 2018 at 11:30 AM Romain Manni-Bucau < >>>>>> rmannibu...@gmail.com> wrote: >>>>>> >>>>>>> Any of you using the idea 2018? the import works for me but then it >>>>>>> is >>>>>>> not as smooth as it seems for you. I'm just trying to see if it is a >>>>>>> procedure thing or a version issue. >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>>>>> >>>>>>> >>>>>>> 2018-04-11 17:28 GMT+02:00 Kenneth Knowles <k...@google.com>: >>>>>>> > The only reason I did "empty project then add a module" procedure >>>>>>> was to get >>>>>>> > all the IntelliJ files outside the source tree. IIRC directly >>>>>>> creating from >>>>>>> > existing sources didn't give the necessary configuration options. >>>>>>> If you >>>>>>> > don't care about being able to `git clean` then you can do the >>>>>>> shorter >>>>>>> > version. Also the particular UI for creation might have improved >>>>>>> since I >>>>>>> > tried it. I'll do it again. >>>>>>> > >>>>>>> > On the pom, since it is only generated for machine reading, why >>>>>>> care if the >>>>>>> > parent is inlined? I actually prefer to avoid coupling with things >>>>>>> that you >>>>>>> > have to go and look up. Using inheritance is OK for human edited >>>>>>> poms >>>>>>> > (actually IMO it is still a mistake) but it doesn't change the >>>>>>> semantics of >>>>>>> > a shipped pom if they are all immutable, which they should be. It >>>>>>> is better >>>>>>> > to have all the info right there. Is there an actually effective >>>>>>> difference? >>>>>>> > >>>>>>> > Kenn >>>>>>> > >>>>>>> > On Wed, Apr 11, 2018 at 6:53 AM Etienne Chauchot < >>>>>>> echauc...@apache.org> >>>>>>> > wrote: >>>>>>> >> >>>>>>> >> Hi all, >>>>>>> >> I just tested gradle environment from a fresh source clone with >>>>>>> this >>>>>>> >> procedure with just a tiny change: I used "new project from >>>>>>> existing >>>>>>> >> sources" rather than create empty project and then add module. >>>>>>> >> >>>>>>> >> It works fine and junit runs from intellij also work. with >>>>>>> gradle we pay >>>>>>> >> a 2s delay (on my machine) before running the actual test for >>>>>>> each run. This >>>>>>> >> delay seems quite constant no matter the module: I have run all >>>>>>> the tests at >>>>>>> >> once in runner-core and a single test in another module with a >>>>>>> similar >>>>>>> >> delay. >>>>>>> >> >>>>>>> >> I also tested a debug session from intellij and it runs fine also. >>>>>>> >> >>>>>>> >> I'll do some more testing and keep you posted. >>>>>>> >> >>>>>>> >> I still have some concerns about the potential difficulty for new >>>>>>> >> contributors to have to learn gradle in addition to Beam itself >>>>>>> comparing to >>>>>>> >> maven which is more mainstream for java developers. That could be >>>>>>> >> discouraging for ex for part-time contributors >>>>>>> >> >>>>>>> >> Etienne >>>>>>> >> >>>>>>> >> Le mardi 10 avril 2018 à 14:38 +0000, Lukasz Cwik a écrit : >>>>>>> >> >>>>>>> >> beam-site PR/414 updates the instructions for using Intellij and >>>>>>> how to >>>>>>> >> import a module: >>>>>>> >> >>>>>>> >> 1. Create an empty IntelliJ project outside of the Beam source >>>>>>> tree. >>>>>>> >> 2. Under Project Structure > Project, select a Project SDK. >>>>>>> >> 3. Under Project Structure > Modules, click the + sign to add a >>>>>>> module and >>>>>>> >> select "Import Module". >>>>>>> >> 1. Select the directory containing the Beam source tree. >>>>>>> >> 2. Tick the "Import module from external model" button and >>>>>>> select >>>>>>> >> Gradle >>>>>>> >> from the list. >>>>>>> >> 3. Tick the following boxes. >>>>>>> >> * Use auto-import >>>>>>> >> * Create separate module per source set >>>>>>> >> * Store generated project files externally >>>>>>> >> * Use default gradle wrapper >>>>>>> >> 4. Delegate build actions to Gradle by going to Settings > Build, >>>>>>> >> Execution, >>>>>>> >> Deployment > Build Tools > Gradle and checking "Delegate IDE >>>>>>> build/run >>>>>>> >> actions to gradle". >>>>>>> >> >>>>>>> >> On Tue, Apr 10, 2018 at 10:34 AM Jean-Baptiste Onofré < >>>>>>> j...@nanthrax.net> >>>>>>> >> wrote: >>>>>>> >> >>>>>>> >> That's a very important issue for contribution. Up to now, I used >>>>>>> Maven >>>>>>> >> for setup IntelliJ (and it works just fine). If we remove the >>>>>>> pom.xml, >>>>>>> >> we have to support Eclipse and IntelliJ "smoothly". >>>>>>> >> >>>>>>> >> Let me try in IntelliJ. >>>>>>> >> >>>>>>> >> Regards >>>>>>> >> JB >>>>>>> >> >>>>>>> >> On 10/04/2018 15:21, Romain Manni-Bucau wrote: >>>>>>> >> > You dont have issue due to the build setup with that option. I >>>>>>> get: >>>>>>> >> > >>>>>>> >> > avr. 10, 2018 3:20:10 PM >>>>>>> >> > org.apache.beam.runners.direct.DirectTransformExecutor run >>>>>>> >> > GRAVE: Error occurred within >>>>>>> >> > org.apache.beam.runners.direct.DirectTransformExecutor@66761b7a >>>>>>> >> > com.google.common.util.concurrent.ExecutionError: >>>>>>> >> > java.lang.NoClassDefFoundError: net/bytebuddy/NamingStrategy >>>>>>> >> > >>>>>>> >> > ? >>>>>>> >> > >>>>>>> >> > Romain Manni-Bucau >>>>>>> >> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > 2018-04-10 15:13 GMT+02:00 Lukasz Cwik <lc...@google.com>: >>>>>>> >> >> I have found that the simplest setup is to delegate the >>>>>>> build/test >>>>>>> >> >> actions >>>>>>> >> >> to Gradle. This allows you to run unit tests very easily and >>>>>>> since its >>>>>>> >> >> in >>>>>>> >> >> the same manner that Gradle would have, you know that if its >>>>>>> passing it >>>>>>> >> >> will >>>>>>> >> >> pass on the command line and on Jenkins. Here is one site that >>>>>>> >> >> discusses how >>>>>>> >> >> to set this up: >>>>>>> >> >> >>>>>>> >> >> >>>>>>> http://mrhaki.blogspot.com/2016/11/gradle-goodness-delegate-build-and-run.html >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> On Tue, Apr 10, 2018 at 8:45 AM Romain Manni-Bucau >>>>>>> >> >> <rmannibu...@gmail.com> >>>>>>> >> >> wrote: >>>>>>> >> >>> >>>>>>> >> >>> What's the plan to make idea supporting gradle on beam >>>>>>> project? Do we >>>>>>> >> >>> import the workaround mentionned in >>>>>>> >> >>> https://youtrack.jetbrains.com/issue/IDEA-175172? >>>>>>> >> >>> For the ones who didn't see this issue in action: idea will >>>>>>> compile in >>>>>>> >> >>> out/ instead of build/ and you will just miss all the >>>>>>> resources you >>>>>>> >> >>> need like some SPI registration which are used by all our >>>>>>> registrar => >>>>>>> >> >>> no way to run tests in idea without hacking the configuration >>>>>>> quite >>>>>>> >> >>> deeply :( >>>>>>> >> >>> >>>>>>> >> >>> Romain Manni-Bucau >>>>>>> >> >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>>>>> >> >>> >>>>>>> >> >>> >>>>>>> >> >>> 2018-04-10 10:08 GMT+02:00 Etienne Chauchot < >>>>>>> echauc...@apache.org>: >>>>>>> >> >>>> As a gradle beginner, I could not agree more ! >>>>>>> >> >>>> +1 >>>>>>> >> >>>> Etienne >>>>>>> >> >>>> Le lundi 09 avril 2018 à 18:47 +0200, Jean-Baptiste Onofré a >>>>>>> écrit : >>>>>>> >> >>>> >>>>>>> >> >>>> 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 >>>>>>> >> >>>> <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> >>>>>>> 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" <k...@google.com >>>>>>> >> >>>> <mailto:k...@google.com>> 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 >>>>>>> >> >>>> <lc...@google.com >>>>>>> >> >>>> <mailto:lc...@google.com>> 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 >>>>>>> >> >>>> <rmannibu...@gmail.com <mailto: >>>>>>> rmannibu...@gmail.com>> >>>>>>> >> >>>> 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 >>>>>>> >> >>>> <sweg...@google.com <mailto: >>>>>>> sweg...@google.com>>: >>>>>>> >> >>>> >>>>>>> >> >>>> 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 >>>>>>> >> >>>> >>>>>>> >> >>>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> >>>>> >>>
