Reuven's point is good.

Once we hit the bare minimum of having things working, let's collect
usability improvements and engineering improvements on a separate JIRA from
the main migration.

I filed https://issues.apache.org/jira/browse/BEAM-4045 for these less
critical issues to separate them from blockers on
https://issues.apache.org/jira/browse/BEAM-3249.

Once we are through the migration, I expect the subtasks might just be
flattened to top-level tasks, but this is a nice view of them.

Kenn

On Tue, Apr 10, 2018 at 1: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