osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Gradle for the build ?


Thanks for bringing this up, JB! I think we are all very eager to do something about the current situation.

Frankly, I agree with Reuven/Łukasz - going back at this point will come at a huge cost. I think going Maven -> Gradle is much easier than going the opposite way.

The situation is not that bad. The build system works ok but there are some rough edges. The main problem for me is the IDE support which seems like it could be fixed if somebody looked into this a bit more. Build time was worse with Maven. Build reliability has been ok for me.

Maybe the team/person mainly involved in the Gradle refactoring could comment on this as well?

-Max

On 09.10.18 11:50, Łukasz Gajowy wrote:
Thanks for starting this thread.

I would go for 1. To all the problems that you described I'd add improving documentation - there are still some places that have only maven instructions (eg. word count examples). There already are some docs that provide help [1], [2]. Should we incorporate them to Beam's confluence?

I don't think 2 is the way to go. All the problems described above do not seem to be unfixable (are the issues with the current Gradle setup are impossible to fix?). We should focus on the fixes not on bringing back maven and adapting it to current requirements.

FWIW, from my experience in working on contributions, I'm not affected by the first three problems that you described. I rarely need to build the whole project and I never had problems with daemon and parallel builds. It is also easier for me to work with Gradle thanks to its great DSL and composable tasks.

Łukasz

[1] https://docs.google.com/document/d/1wR56Jef3XIPwj4DFzQKznuGPM3JDfRDVkxzeDlbdVSQ/edit?usp=sharing [2] https://docs.google.com/document/d/1EiTwEMD8FNhU4Ok6jthASpmK3-1hiAYzVTrdl8qBLrs/edit?usp=sharing

wt., 9 paź 2018 o 10:25 Reuven Lax <relax@xxxxxxxxxx <mailto:relax@xxxxxxxxxx>> napisał(a):

    I'm not going to comment too much on most of these points (as I
    think others can do so better). However I think that the effort
    required to migrate back to Maven will actually be quite
    significant. Much has been added to Beam (both to the codebase, and
    to our Jenkins tooling, etc.) since we moved to Gradle, and none of
    this has been added to Maven. I believe that going back and
    migrating all of this to Maven will be difficult at this point.

    I would vote for option 1.  I believe that many of the current
    issues are easily fixable. For example, requiring no-parallel I
    believe is because some of our dependencies are incorrectly setup in
    gradle files, and nobody has taken the time to track this down and
    fix it (it was easier to just start setting that flag).

    Reuven

    On Tue, Oct 9, 2018 at 1:04 AM Jean-Baptiste Onofré <jb@xxxxxxxxxxxx
    <mailto:jb@xxxxxxxxxxxx>> wrote:

        Hi guys,

        I know that's a hot topic, but I have to bring this discussion
        on the table.

        Some months ago, we discussed about migrating our build from
        Maven to
        Gradle. One of the key expected improvement was the time to build.
        We proposed to do a PoC to evaluate the impacts and
        improvements, but
        this PoC was actually directly a migrate on master.

        Now, I would like to bring facts here:

        1. Build time
        On my machine, the build time is roughly 1h15. It's pretty long, and
        regarding what the build is doing, I don't see huge improvement
        provided
        by Gradle.
        2. Build reliability
        Even worse, most of the time, we need to use --no-parallel and
        --no-daemon to have a reliable build (it's basically recommended for
        release). It has an impact on build time, and we loose part of
        Gradle
        benefits.
        3. Release and repositories
        Even if couple of releases has been performed with Gradle, it's not
        obvious to see improvements around artifacts handling. I got my
        repository polluted twice (that's part of the trick Gradle is
        doing to
        speed up the build dealing around the repository).
        4. IDE integration
        We already had some comments on the mailing lists about the IDE
        integration. Clearly, the situation is not good on that front
        too. The
        integration on IDE (especially IntelliJ) is not good enough
        right now.

        We are working hard to grow up the community, and from a contributor
        perspective, our build system is not good today IMHO.
        As a contributor, I resumed my work on some PRs, and I'm spending so
        much time of the build, largely more than working on the PRs
        code itself.

        So, obviously, the situation is not perfect, at least from a
        contributor
        perspective.

        The purpose of this thread is not again to have a bunch of replied
        ending nowhere. I would like to be more "pushy" and let's try to be
        concrete. So basically, we only have two options:

        1. Improve the build, working hard on Gradle front. Not sure if
        it makes
        such sense from a contributor perspective, as Maven is really
        well known
        from most of contributors (and easier to start with IMHO).
        2. Back on Maven. That's clearly my preferred approach. IDE
        integration
        is better, Maven is well known from the contributors as already
        said.
        The effort is not so huge. We tried to use Gradle, we don't have the
        expected results now, that's not a problem, it's part of a
        project lifetime.

        Thoughts ?

        Regards
        JB

-- Jean-Baptiste Onofré
        jbonofre@xxxxxxxxxx <mailto:jbonofre@xxxxxxxxxx>
        http://blog.nanthrax.net
        Talend - http://www.talend.com