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 >>>>>>>>>>> >> >>>> >>>>>>>>>>> >> >>>> >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >
