Well it is yes and no (build -> fails, build -> succeeds is weird for solething harnessing your code).
Anyway, idea forces a clean to ensure the test you select runs. Le 15 avr. 2018 19:58, "Kenneth Knowles" <[email protected]> a écrit : > Caching success/failure of a test is legitimate useful behavior. That > said, I'm not sure how it interacts with Idea. > > Kenn > > On Sun, Apr 15, 2018 at 12:23 AM Romain Manni-Bucau <[email protected]> > wrote: > >> If you dont the diff is empty and gradle runs nothing, no? Saw it with >> gradle 4.6 >> >> Le 15 avr. 2018 00:49, "Kenneth Knowles" <[email protected]> a écrit : >> >>> You shouldn't do :module:cleanTest. If that is necessary that's a major >>> bug in the build. >>> >>> Kenn >>> >>> On Fri, Apr 13, 2018 at 11:46 PM Romain Manni-Bucau < >>> [email protected]> wrote: >>> >>>> There is a fake module xxx_test which should have the right classpath >>>> but since idea compilation is messed up you will still have to run >>>> :module:cleanTest :module:test --tests org...MyTest.myMethod, even with >>>> idea which leads to the same latency as the command line :( >>>> >>>> Le 13 avr. 2018 22:23, "Eugene Kirpichov" <[email protected]> a >>>> écrit : >>>> >>>>> While we're talking about running tests in IntelliJ with Gradle... >>>>> Anybody got advice on how to run a single NeedsRunner test in >>>>> sdks-java-core, say, ParDoTest? With Maven, I used to just run the test in >>>>> IntelliJ and specify "runners-direct-java" as the classpath; with Gradle, >>>>> the best I got is to manually run the direct runner's needsRunnerTests >>>>> task >>>>> with specifying --tests=..., but it takes a long time, and IntelliJ treats >>>>> that as just a gradle task run, not as a test run. >>>>> >>>>> On Fri, Apr 13, 2018 at 11:14 AM Reuven Lax <[email protected]> wrote: >>>>> >>>>>> Is there a Jira for this 3 second delay? Also you're initial >>>>>> complaint was not about the 3 second delay, so it wasn't clear that's >>>>>> what >>>>>> you were complaining about. >>>>>> >>>>>> Reuven >>>>>> >>>>>> On Fri, Apr 13, 2018 at 4:42 AM Romain Manni-Bucau < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> When you launch a test with gradle runner it launches gradle which >>>>>>> makes loose 3s on a very fast computer and more on a slower (6 on my >>>>>>> personal one which is already fast but not as much as my work one). We >>>>>>> are >>>>>>> 5 to see that regression at least. So there is a reason to not use the >>>>>>> gradle runner if possible cause when you work and need to debug you are >>>>>>> just stucked (that is why i switched back to mvn after 15mn, i was >>>>>>> loosing >>>>>>> to much time). >>>>>>> >>>>>>> Switching back to native idea test run would fix it but tests just >>>>>>> dont work this way for me whatever setup i do :( - missing resources >>>>>>> IIRC >>>>>>> in idea out dir. >>>>>>> >>>>>>> Le 13 avr. 2018 00:07, "Reuven Lax" <[email protected]> a écrit : >>>>>>> >>>>>>> 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 >>>>>>>>>>>>>>>>> >> >>>> >>>>>>>>>>>>>>>>> >> >>>> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>
