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" <k...@google.com> 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 <rmannibu...@gmail.com>
> 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" <k...@google.com> 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 <
>>> rmannibu...@gmail.com> 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" <kirpic...@google.com> 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 <re...@google.com> 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 <
>>>>>> rmannibu...@gmail.com> 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" <re...@google.com> 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 <
>>>>>>> danolive...@google.com> 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 <
>>>>>>>> rmannibu...@gmail.com> 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" <danolive...@google.com>
>>>>>>>>> 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 <
>>>>>>>>>> rmannibu...@gmail.com> 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" <danolive...@google.com>
>>>>>>>>>>> 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 <
>>>>>>>>>>>> aromanenko....@gmail.com> 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 <
>>>>>>>>>>>>> danolive...@google.com> 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 <
>>>>>>>>>>>>> rmannibu...@gmail.com> 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" <
>>>>>>>>>>>>>> aromanenko....@gmail.com> 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 <
>>>>>>>>>>>>>>> danolive...@google.com> 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 <
>>>>>>>>>>>>>>> lc...@google.com> 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 <
>>>>>>>>>>>>>>>> rmannibu...@gmail.com> 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 <k...@google.com
>>>>>>>>>>>>>>>>> >:
>>>>>>>>>>>>>>>>> > 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 <
>>>>>>>>>>>>>>>>> echauc...@apache.org>
>>>>>>>>>>>>>>>>> > 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é <
>>>>>>>>>>>>>>>>> j...@nanthrax.net>
>>>>>>>>>>>>>>>>> >> 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 <
>>>>>>>>>>>>>>>>> lc...@google.com>:
>>>>>>>>>>>>>>>>> >> >> 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
>>>>>>>>>>>>>>>>> >> >> <rmannibu...@gmail.com>
>>>>>>>>>>>>>>>>> >> >> 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 <
>>>>>>>>>>>>>>>>> echauc...@apache.org>:
>>>>>>>>>>>>>>>>> >> >>>> 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
>>>>>>>>>>>>>>>>> >> >>>> <rmannibu...@gmail.com <mailto:
>>>>>>>>>>>>>>>>> rmannibu...@gmail.com>> 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" <
>>>>>>>>>>>>>>>>> k...@google.com
>>>>>>>>>>>>>>>>> >> >>>>      <mailto:k...@google.com>> 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
>>>>>>>>>>>>>>>>> >> >>>> <lc...@google.com
>>>>>>>>>>>>>>>>> >> >>>>          <mailto:lc...@google.com>> 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
>>>>>>>>>>>>>>>>> >> >>>>              <rmannibu...@gmail.com <mailto:
>>>>>>>>>>>>>>>>> rmannibu...@gmail.com>>
>>>>>>>>>>>>>>>>> >> >>>> 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
>>>>>>>>>>>>>>>>> >> >>>>                  <sweg...@google.com <mailto:
>>>>>>>>>>>>>>>>> sweg...@google.com>>:
>>>>>>>>>>>>>>>>> >> >>>>
>>>>>>>>>>>>>>>>> >> >>>>                      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
>>>>>>>>>>>>>>>>> >> >>>>
>>>>>>>>>>>>>>>>> >> >>>>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>

Reply via email to