Sorry Romain, I'm not quite sure what you're asking. Can you clarify? On Thu, Apr 12, 2018 at 12:22 PM Romain Manni-Bucau <[email protected]> wrote:
> Well you are the only one to not have the drawbacks to use it so maybe > dont do it? I know Luke is in holidays but anyone else with the knowledge > of why we nees that noise compared to idea native tooling/flow? > > Le 12 avr. 2018 20:16, "Daniel Oliveira" <[email protected]> a > écrit : > >> 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 < >> [email protected]> 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" <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 < >>>>> [email protected]> 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" <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 <[email protected]>: >>>>>>>>> > 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 < >>>>>>>>> [email protected]> >>>>>>>>> > 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é < >>>>>>>>> [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]>: >>>>>>>>> >> >> 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]> >>>>>>>>> >> >> 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]>: >>>>>>>>> >> >>>> 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]>> >>>>>>>>> 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 >>>>>>>>> >> >>>> >>>>>>>>> >> >>>> >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>> >>>>>
