Actually I always found the right-click to run tests to only sometimes work
in Maven, especially if there were changes to dependent AutoValue classes
where code had to be generated. Too often it would fail, and I would then
need to use Maven to rebuild the whole project. It would be cool if Gradle
could do this more reliably than Maven did.

Reuven

On Tue, Apr 10, 2018 at 8:46 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> @jb: what did you change? I re-imported the project like 3 times earlier
> today and never got it working acceptably :(
>
> Personally if importing the project and right click on a test+debug works
> as good as maven in idea id be happy. I can manage other stuff in a console
> even if gradle reporting is not that efficient for me for now.
>
> Le 10 avr. 2018 21:37, "Reuven Lax" <re...@google.com> a écrit :
>
>> There are a lot of ideas on how to increase usability, but I think
>> they'll get lost in the thread. I suggest we try to capture them in Jiras.
>>
>> I suggest we also find out what common use patterns are (people on this
>> thread are probably sufficient), as different people will have different
>> workflows. We can then make sure that all common workflows are documented.
>> As an example, one task I often do is to run just checkstyle over a module
>> or the entire project.
>>
>> Reuven
>>
>> On Tue, Apr 10, 2018 at 7:18 PM Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>
>>> FYI, I did a new attempt and it works fine (pretty long). Previous try
>>> failed.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/04/2018 19:52, Kenneth Knowles wrote:
>>> > I've been on Idea+Gradle for ~two months, around the time I added
>>> > https://github.com/apache/beam/pull/4583 and
>>> > https://github.com/apache/beam/pull/4626 to make the import require
>>> zero
>>> > user work. I have no fear of deleting my project any time and
>>> re-importing.
>>> >
>>> > I agree with not having auto-import on. It is just too slow. I can't
>>> > remember if it was importing too often due to build outputs or if it
>>> was
>>> > just that I was messing with the build.gradle files. Anyhow it doesn't
>>> > really add much value.
>>> >
>>> > The gradle runner _is_ able to use submodules and run individual tests
>>> > methods, and all that.
>>> >
>>> > Kenn
>>> >
>>> >
>>> > On Tue, Apr 10, 2018 at 9:31 AM Romain Manni-Bucau
>>> > <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> wrote:
>>> >
>>> >     Runner a test doesnt have the right classpath (idea uses out/
>>> instead
>>> >     of build/) then when you switch on gradle runner the launching uses
>>> >     gradle which is not able to use submodules directly but reconsider
>>> the
>>> >     whole project which is quite slow for normal dev iterations
>>> >     compare to just run the test with the right classpath and a fast
>>> >     compile step if needed. I lost literally 1h for something simple
>>> with
>>> >     that tooling, this is way too much to be acceptable on my side
>>> since
>>> >     I'm sadly not paid to work on beam (one day maybe ;)).
>>> >
>>> >     Romain Manni-Bucau
>>> >     @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> >
>>> >
>>> >     2018-04-10 18:27 GMT+02:00 Reuven Lax <re...@google.com
>>> >     <mailto:re...@google.com>>:
>>> >      > Romain,
>>> >      >
>>> >      > Can you detail what's not working. I switched my IntelliJ over
>>> to
>>> >     Gradle
>>> >      > about two weeks ago, and haven't had any trouble.
>>> >      >
>>> >      > Reuven
>>> >      >
>>> >      > On Tue, Apr 10, 2018 at 4:20 PM Romain Manni-Bucau
>>> >     <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
>>> >      > wrote:
>>> >      >>
>>> >      >> Ok, didn't find a way to make it working properly (only
>>> workaround
>>> >      >> with direct commands and no good idea integration for
>>> >     debugging). I'm
>>> >      >> back with maven, if anyone knows how to properly solve it let's
>>> >     do it.
>>> >      >> If not I think JB point is to consider more than any other
>>> criteria.
>>> >      >>
>>> >      >> Romain Manni-Bucau
>>> >      >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> >      >>
>>> >      >>
>>> >      >> 2018-04-10 16:41 GMT+02:00 Romain Manni-Bucau
>>> >     <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>:
>>> >      >> > side note: do NOT use auto-import until you are sure you can,
>>> >     it locks
>>> >      >> > regularly on beam (pby too big for idea?) and makes idea
>>> ready
>>> >     to be
>>> >      >> > killed :(
>>> >      >> >
>>> >      >> > Romain Manni-Bucau
>>> >      >> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> >      >> >
>>> >      >> >
>>> >      >> > 2018-04-10 16:40 GMT+02:00 Jean-Baptiste Onofré
>>> >     <j...@nanthrax.net <mailto:j...@nanthrax.net>>:
>>> >      >> >> It's what I did, I'm trying a complete reload now (maybe
>>> this
>>> >     step
>>> >      >> >> failed).
>>> >      >> >>
>>> >      >> >> On 10/04/2018 16:38, Lukasz Cwik wrote:
>>> >      >> >>>
>>> >      >> >>> 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 <mailto:j...@nanthrax.net>
>>> >      >> >>> <mailto:j...@nanthrax.net <mailto: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 <mailto:lc...@google.com>
>>> >      >> >>>     <mailto:lc...@google.com <mailto: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 <mailto:rmannibu...@gmail.com>
>>> >     <mailto:rmannibu...@gmail.com <mailto: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 <mailto:echauc...@apache.org>
>>> >     <mailto:echauc...@apache.org <mailto: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> <mailto:rmannibu...@gmail.com
>>> >     <mailto:rmannibu...@gmail.com>>
>>> >      >> >>>     <mailto:rmannibu...@gmail.com
>>> >     <mailto:rmannibu...@gmail.com> <mailto: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>
>>> >      >> >>>     <mailto:k...@google.com <mailto:k...@google.com>>
>>> >      >> >>>      >>>>      <mailto:k...@google.com
>>> >     <mailto:k...@google.com> <mailto: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>
>>> >     <mailto:lc...@google.com <mailto:lc...@google.com>>
>>> >      >> >>>      >>>>          <mailto:lc...@google.com
>>> >     <mailto:lc...@google.com>
>>> >      >> >>> <mailto: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>
>>> >      >> >>>     <mailto:rmannibu...@gmail.com
>>> >     <mailto:rmannibu...@gmail.com>> <mailto:rmannibu...@gmail.com
>>> >     <mailto:rmannibu...@gmail.com>
>>> >      >> >>>     <mailto: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>
>>> >      >> >>>     <mailto:sweg...@google.com <mailto:sweg...@google.com
>>> >>
>>> >     <mailto:sweg...@google.com <mailto:sweg...@google.com>
>>> >      >> >>>
>>> >      >> >>>     <mailto: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