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