Reuven's point is good. Once we hit the bare minimum of having things working, let's collect usability improvements and engineering improvements on a separate JIRA from the main migration.
I filed https://issues.apache.org/jira/browse/BEAM-4045 for these less critical issues to separate them from blockers on https://issues.apache.org/jira/browse/BEAM-3249. Once we are through the migration, I expect the subtasks might just be flattened to top-level tasks, but this is a nice view of them. Kenn On Tue, Apr 10, 2018 at 1:46 PM Romain Manni-Bucau <[email protected]> wrote: > @jb: what did you change? I re-imported the project like 3 times earlier > today and never got it working acceptably :( > > Personally if importing the project and right click on a test+debug works > as good as maven in idea id be happy. I can manage other stuff in a console > even if gradle reporting is not that efficient for me for now. > > Le 10 avr. 2018 21:37, "Reuven Lax" <[email protected]> a écrit : > >> There are a lot of ideas on how to increase usability, but I think >> they'll get lost in the thread. I suggest we try to capture them in Jiras. >> >> I suggest we also find out what common use patterns are (people on this >> thread are probably sufficient), as different people will have different >> workflows. We can then make sure that all common workflows are documented. >> As an example, one task I often do is to run just checkstyle over a module >> or the entire project. >> >> Reuven >> >> On Tue, Apr 10, 2018 at 7:18 PM Jean-Baptiste Onofré <[email protected]> >> wrote: >> >>> FYI, I did a new attempt and it works fine (pretty long). Previous try >>> failed. >>> >>> Regards >>> JB >>> >>> On 10/04/2018 19:52, Kenneth Knowles wrote: >>> > I've been on Idea+Gradle for ~two months, around the time I added >>> > https://github.com/apache/beam/pull/4583 and >>> > https://github.com/apache/beam/pull/4626 to make the import require >>> zero >>> > user work. I have no fear of deleting my project any time and >>> re-importing. >>> > >>> > I agree with not having auto-import on. It is just too slow. I can't >>> > remember if it was importing too often due to build outputs or if it >>> was >>> > just that I was messing with the build.gradle files. Anyhow it doesn't >>> > really add much value. >>> > >>> > The gradle runner _is_ able to use submodules and run individual tests >>> > methods, and all that. >>> > >>> > Kenn >>> > >>> > >>> > On Tue, Apr 10, 2018 at 9:31 AM Romain Manni-Bucau >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > Runner a test doesnt have the right classpath (idea uses out/ >>> instead >>> > of build/) then when you switch on gradle runner the launching uses >>> > gradle which is not able to use submodules directly but reconsider >>> the >>> > whole project which is quite slow for normal dev iterations >>> > compare to just run the test with the right classpath and a fast >>> > compile step if needed. I lost literally 1h for something simple >>> with >>> > that tooling, this is way too much to be acceptable on my side >>> since >>> > I'm sadly not paid to work on beam (one day maybe ;)). >>> > >>> > Romain Manni-Bucau >>> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>> > >>> > >>> > 2018-04-10 18:27 GMT+02:00 Reuven Lax <[email protected] >>> > <mailto:[email protected]>>: >>> > > Romain, >>> > > >>> > > Can you detail what's not working. I switched my IntelliJ over >>> to >>> > Gradle >>> > > about two weeks ago, and haven't had any trouble. >>> > > >>> > > Reuven >>> > > >>> > > On Tue, Apr 10, 2018 at 4:20 PM Romain Manni-Bucau >>> > <[email protected] <mailto:[email protected]>> >>> > > wrote: >>> > >> >>> > >> Ok, didn't find a way to make it working properly (only >>> workaround >>> > >> with direct commands and no good idea integration for >>> > debugging). I'm >>> > >> back with maven, if anyone knows how to properly solve it let's >>> > do it. >>> > >> If not I think JB point is to consider more than any other >>> criteria. >>> > >> >>> > >> Romain Manni-Bucau >>> > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>> > >> >>> > >> >>> > >> 2018-04-10 16:41 GMT+02:00 Romain Manni-Bucau >>> > <[email protected] <mailto:[email protected]>>: >>> > >> > side note: do NOT use auto-import until you are sure you can, >>> > it locks >>> > >> > regularly on beam (pby too big for idea?) and makes idea >>> ready >>> > to be >>> > >> > killed :( >>> > >> > >>> > >> > Romain Manni-Bucau >>> > >> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>> > >> > >>> > >> > >>> > >> > 2018-04-10 16:40 GMT+02:00 Jean-Baptiste Onofré >>> > <[email protected] <mailto:[email protected]>>: >>> > >> >> It's what I did, I'm trying a complete reload now (maybe >>> this >>> > step >>> > >> >> failed). >>> > >> >> >>> > >> >> On 10/04/2018 16:38, Lukasz Cwik wrote: >>> > >> >>> >>> > >> >>> 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é >>> > <[email protected] <mailto:[email protected]> >>> > >> >>> <mailto:[email protected] <mailto:[email protected]>>> 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 >>> > <[email protected] <mailto:[email protected]> >>> > >> >>> <mailto:[email protected] <mailto:[email protected]>>>: >>> > >> >>> >> 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 >>> > >> >>> <[email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> >>> > >> >>> >> 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 >>> > >> >>> <[email protected] <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>>: >>> > >> >>> >>> > >> >>> >>>> 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 >>> > >> >>> >>>> <[email protected] >>> > <mailto:[email protected]> <mailto:[email protected] >>> > <mailto:[email protected]>> >>> > >> >>> <mailto:[email protected] >>> > <mailto:[email protected]> <mailto:[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]> >>> > >> >>> <mailto:[email protected] <mailto:[email protected]>> >>> > >> >>> >>>> <mailto:[email protected] >>> > <mailto:[email protected]> <mailto:[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]> >>> > <mailto:[email protected] <mailto:[email protected]>> >>> > >> >>> >>>> <mailto:[email protected] >>> > <mailto:[email protected]> >>> > >> >>> <mailto:[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]> >>> > >> >>> <mailto:[email protected] >>> > <mailto:[email protected]>> <mailto:[email protected] >>> > <mailto:[email protected]> >>> > >> >>> <mailto:[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]> >>> > >> >>> <mailto:[email protected] <mailto:[email protected] >>> >> >>> > <mailto:[email protected] <mailto:[email protected]> >>> > >> >>> >>> > >> >>> <mailto:[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 >>> > >> >>> >>>> >>> > >> >>> >>>> >>> > >> >>> >>> > >> >> >>> > >>> >>
