I also don't quite understand what your question is, and it appears like Dan spent considerable time trying to reproduce your issue. For the record, I have had no issues running tests via Gradle in IntelliJ for the past few weeks.
Reuven On Thu, Apr 12, 2018 at 9:47 PM Daniel Oliveira <[email protected]> wrote: > 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 >>>>>>>>>> >> >>>> >>>>>>>>>> >> >>>> >>>>>>>>>> >> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>
