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 ?


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

                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

                    * 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
                    [5] https://github.com/apache/beam/pull/5003


                    Got feedback? http://go/swegner-feedback


Got feedback? http://go/swegner-feedback

Reply via email to