beam-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Knowles <>
Subject Re: Removing shading by default within BeamModulePlugin.groovy
Date Wed, 05 Jun 2019 02:18:25 GMT
Nice! This is a huge step. One thing that showed up in the last big gradle
change was needing to check the generated poms.


On Tue, Jun 4, 2019 at 5:07 PM Lukasz Cwik <> wrote:

> Since we have been migrating to using vendoring instead of shading[1] and
> due to previous efforts in vendoring[2, 3] I have opened up PR 8762[4]
> which migrates all projects that weren't doing anything shading wise to not
> perform any shading. This required me to fix up all intra project
> dependencies and release publishing.
> The following is a list of all project paths which are still using shading
> for some reason:
> model/*
> sdks/java/core
> sdks/java/extensions/kryo
> sdks/java/extensions/sql
> sdks/java/extensions/sql/jdbc
> sdks/java/harness
> runners/spark/job-server
> runners/direct-java
> runners/samza/job-server
> runners/google-cloud-dataflow-java/worker
> runners/google-cloud-dataflow-java/worker/legacy-worker
> runners/google-cloud-dataflow-java/worker/windmill
> vendor/*
> Out of the list above, migrating sdks/java/core and runners/direct-java
> (in that order) would provide the most benefit to moving away from shading
> within our project. Many of the others are either shaded proto classes or
> applications (e.g. job-servers, harness, sql jdbc) and either require
> shading to be compatible with vendoring or aren't meant to be used as
> dependencies.
> Since this is a larger change that cuts across so many projects there is
> risk for breakage. I'm looking for people to help test the change and
> validate any scenarios that they are specifically interested in. I'm
> planning to run several of the postcommits on my PR and check that we can
> build a release in addition to any efforts others provide before looking to
> have the change merged.
> The following guidance should help those who edit Gradle build files
> (after this change is merged):
> * For projects that don't perform any shading, those projects have been
> migrated to use the default configurations that the Gradle Java plugin
> uses[5]. Note that the default configurations we use have been deprecated.
> * For projects that depend on another project that isn't shaded, the intra
> project configuration has been swapped to use compile / testRuntime instead
> of shadow and shadowTest
> * Existing projects that are still shaded should use the shadow and
> shadowTest configurations as before.
> 1:
> 2:
> 3:
> 4:
> 5:

View raw message