You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Luke Cwik <lc...@google.com> on 2021/12/30 17:45:13 UTC
Gradle 7 migration
The migration to gradle 7[1] happened in the past two weeks. As part of
that migration many plugins had to be updated or replaced if a newer gradle
7 compatible version couldn't be found and dependencies were moved away
from the removed configurations such as "compile" and "testCompile" (more
on this below). If you experience issues during your development process
that you suspect is due to the migration, feel free to reach out.
For the removed configurations (boxes with light gray text), the gradle
migration guide[2] suggested that existing usages of "compile" be replaced
with "implementation" and "testCompile" with "testImplementation". Usages
of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
the split of configurations used to declare dependencies (light green) and
configurations that are consumed by tasks (blue gray). A new configuration
called "testRuntimeMigration" was created for the purpose of migrating the
widely used "testRuntime" configuration. The "testRuntimeConfiguration"
contains the current modules test jar and extends the "testRuntimeOnly" and
"testImplementation" configurations effectively creating something similar
to the "testRuntimeClasspath" which can be consumed by tasks and used to
declare dependencies to other modules tests. This seems to be working at
the moment but open to suggestions on how to re-organize this cleanly (e.g.
should jar also add to "testRuntimeMigration").
For the main source set:
[image: image.png]
For the test source set (forgive my paint skills):
[image: image.png]
1: https://issues.apache.org/jira/browse/BEAM-13430
2:
https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
Re: Gradle 7 migration
Posted by Chamikara Jayalath <ch...@google.com>.
> Also xcun is installed on my machine, just not under
Library/Developer/CommandLineTools/. Is there something about the new go
version that's causing it to look in that directory?
For anyone who's still running into this, I had to do the following after
installing Xcode.
* Open xcode app
* In the menu, go to Xcode > Preferences > Locations
* Under "Command Line Tools" select an installed Xcode library if not set.
Thanks,
Cham
On Wed, Jan 5, 2022 at 11:22 AM Luke Cwik <lc...@google.com> wrote:
> There were many ClassNotFoundException issues within our integration tests
> on Jenkins. This was due to the Gradle 7 migration and because the
> testRuntimeMigraiton contained:
> * dependencies
> * test dependencies
> * compiled test source set in a jar artifact
> and was missing:
> * compiled main source set in a jar artifact
>
> https://github.com/apache/beam/pull/16430 addresses this and removes the
> need to add the default project configuration whenever the
> testRuntimeMigration is added.
>
> On Mon, Jan 3, 2022 at 6:31 PM Robert Burke <ro...@frantil.com> wrote:
>
>> As a non-OSX user, I can't tell you. I'll look into it tomorrow.
>>
>>
>>
>> On Mon, Jan 3, 2022, 6:24 PM Reuven Lax <re...@google.com> wrote:
>>
>>> Also xcun is installed on my machine, just not under
>>> Library/Developer/CommandLineTools/. Is there something about the new
>>> go version that's causing it to look in that directory?
>>>
>>> On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote:
>>>
>>>> I was running spotlessApply - which is pretty much a prerequisite for
>>>> submitting any code to Beam.
>>>>
>>>> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
>>>>
>>>>> Xcrun is news to me. Something in the go toolchain for that command I
>>>>> guess. I assume you might not have xcode tools installed. Eg.
>>>>> https://developer.apple.com/forums/thread/673827
>>>>>
>>>>> Were you running the :sdks:go:test target directly?
>>>>>
>>>>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>>>>>
>>>>>> I am trying to run ./gradlew spotlessApply, and I'm getting go
>>>>>> errors. I've updated the go version, but I'm still getting the following
>>>>>> error. Any idea what I'm doing wrong?
>>>>>>
>>>>>> *> Configure project :sdks:go:test*
>>>>>>
>>>>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>>>>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>>>>>
>>>>>> # runtime/cgo
>>>>>>
>>>>>> xcrun: error: invalid active developer path
>>>>>> (/Library/Developer/CommandLineTools), missing xcrun at:
>>>>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>>>>>
>>>>>>
>>>>>> FAILURE: Build failed with an exception.
>>>>>>
>>>>>>
>>>>>> * Where:
>>>>>>
>>>>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>>>>>
>>>>>>
>>>>>> * What went wrong:
>>>>>>
>>>>>> A problem occurred evaluating project ':sdks:go:test'.
>>>>>>
>>>>>> > Could not create task ':sdks:go:test:goPrepare'.
>>>>>>
>>>>>> > Process 'command 'sh'' finished with non-zero exit value 2
>>>>>>
>>>>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Great graphs Luke!
>>>>>>>
>>>>>>> Related note: with this migration the project no longer uses the
>>>>>>> GoGradle plugin to build or test any Go source. They have been replaced
>>>>>>> with shell script that bootstrap to a set version of go. This is tracked
>>>>>>> in BEAM-12830 [1].
>>>>>>>
>>>>>>> This touches all portable builds as the project uses small Go
>>>>>>> programs for portable container bootstrap.
>>>>>>>
>>>>>>> The following are the consequences of this change and known issues:
>>>>>>>
>>>>>>> * The project requires a minimum of Go 1.16 to bootstrap to
>>>>>>> arbitrary Go versions going forward.
>>>>>>> * Presently Nightly Snapshots are broken since the shared infra
>>>>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>>>>>> See that for the paired ticket to Infra for upgrading.
>>>>>>>
>>>>>>> * OSX users can't currently run the Go integration tests locally,
>>>>>>> due to the scripts not currently building both the local host platform
>>>>>>> version and the container required version of pipelines.
>>>>>>> * This is a small inconvenience as it only prevents using the
>>>>>>> gradle scripts, and not using beam by using Go directly.
>>>>>>>
>>>>>>> If there are any other issues related to the removal of GoGradle, or
>>>>>>> either of these limitations become urgent, please let me know so a fix can
>>>>>>> be expedited.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Robert Burke
>>>>>>> Beam Go Busybody
>>>>>>>
>>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>>>>>
>>>>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>>>>>
>>>>>>>> The migration to gradle 7[1] happened in the past two weeks. As
>>>>>>>> part of that migration many plugins had to be updated or replaced if a
>>>>>>>> newer gradle 7 compatible version couldn't be found and dependencies were
>>>>>>>> moved away from the removed configurations such as "compile" and
>>>>>>>> "testCompile" (more on this below). If you experience issues during your
>>>>>>>> development process that you suspect is due to the migration, feel free to
>>>>>>>> reach out.
>>>>>>>>
>>>>>>>> For the removed configurations (boxes with light gray text), the
>>>>>>>> gradle migration guide[2] suggested that existing usages of "compile" be
>>>>>>>> replaced with "implementation" and "testCompile" with "testImplementation".
>>>>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7
>>>>>>>> forced the split of configurations used to declare dependencies (light
>>>>>>>> green) and configurations that are consumed by tasks (blue gray). A new
>>>>>>>> configuration called "testRuntimeMigration" was created for the purpose of
>>>>>>>> migrating the widely used "testRuntime" configuration. The
>>>>>>>> "testRuntimeConfiguration" contains the current modules test jar and
>>>>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations
>>>>>>>> effectively creating something similar to the "testRuntimeClasspath" which
>>>>>>>> can be consumed by tasks and used to declare dependencies to other modules
>>>>>>>> tests. This seems to be working at the moment but open to suggestions on
>>>>>>>> how to re-organize this cleanly (e.g. should jar also add to
>>>>>>>> "testRuntimeMigration").
>>>>>>>>
>>>>>>>> For the main source set:
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>> For the test source set (forgive my paint skills):
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>>
>>>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>>>>>> 2:
>>>>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>>>>>
>>>>>>>
Re: Gradle 7 migration
Posted by Luke Cwik <lc...@google.com>.
There were many ClassNotFoundException issues within our integration tests
on Jenkins. This was due to the Gradle 7 migration and because the
testRuntimeMigraiton contained:
* dependencies
* test dependencies
* compiled test source set in a jar artifact
and was missing:
* compiled main source set in a jar artifact
https://github.com/apache/beam/pull/16430 addresses this and removes the
need to add the default project configuration whenever the
testRuntimeMigration is added.
On Mon, Jan 3, 2022 at 6:31 PM Robert Burke <ro...@frantil.com> wrote:
> As a non-OSX user, I can't tell you. I'll look into it tomorrow.
>
>
>
> On Mon, Jan 3, 2022, 6:24 PM Reuven Lax <re...@google.com> wrote:
>
>> Also xcun is installed on my machine, just not under
>> Library/Developer/CommandLineTools/. Is there something about the new go
>> version that's causing it to look in that directory?
>>
>> On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote:
>>
>>> I was running spotlessApply - which is pretty much a prerequisite for
>>> submitting any code to Beam.
>>>
>>> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
>>>
>>>> Xcrun is news to me. Something in the go toolchain for that command I
>>>> guess. I assume you might not have xcode tools installed. Eg.
>>>> https://developer.apple.com/forums/thread/673827
>>>>
>>>> Were you running the :sdks:go:test target directly?
>>>>
>>>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>>>>
>>>>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
>>>>> I've updated the go version, but I'm still getting the following error. Any
>>>>> idea what I'm doing wrong?
>>>>>
>>>>> *> Configure project :sdks:go:test*
>>>>>
>>>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>>>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>>>>
>>>>> # runtime/cgo
>>>>>
>>>>> xcrun: error: invalid active developer path
>>>>> (/Library/Developer/CommandLineTools), missing xcrun at:
>>>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>>>>
>>>>>
>>>>> FAILURE: Build failed with an exception.
>>>>>
>>>>>
>>>>> * Where:
>>>>>
>>>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>>>>
>>>>>
>>>>> * What went wrong:
>>>>>
>>>>> A problem occurred evaluating project ':sdks:go:test'.
>>>>>
>>>>> > Could not create task ':sdks:go:test:goPrepare'.
>>>>>
>>>>> > Process 'command 'sh'' finished with non-zero exit value 2
>>>>>
>>>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com>
>>>>> wrote:
>>>>>
>>>>>> Great graphs Luke!
>>>>>>
>>>>>> Related note: with this migration the project no longer uses the
>>>>>> GoGradle plugin to build or test any Go source. They have been replaced
>>>>>> with shell script that bootstrap to a set version of go. This is tracked
>>>>>> in BEAM-12830 [1].
>>>>>>
>>>>>> This touches all portable builds as the project uses small Go
>>>>>> programs for portable container bootstrap.
>>>>>>
>>>>>> The following are the consequences of this change and known issues:
>>>>>>
>>>>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary
>>>>>> Go versions going forward.
>>>>>> * Presently Nightly Snapshots are broken since the shared infra
>>>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>>>>> See that for the paired ticket to Infra for upgrading.
>>>>>>
>>>>>> * OSX users can't currently run the Go integration tests locally, due
>>>>>> to the scripts not currently building both the local host platform version
>>>>>> and the container required version of pipelines.
>>>>>> * This is a small inconvenience as it only prevents using the
>>>>>> gradle scripts, and not using beam by using Go directly.
>>>>>>
>>>>>> If there are any other issues related to the removal of GoGradle, or
>>>>>> either of these limitations become urgent, please let me know so a fix can
>>>>>> be expedited.
>>>>>>
>>>>>> Cheers,
>>>>>> Robert Burke
>>>>>> Beam Go Busybody
>>>>>>
>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>>>>
>>>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>>>>
>>>>>>> The migration to gradle 7[1] happened in the past two weeks. As part
>>>>>>> of that migration many plugins had to be updated or replaced if a newer
>>>>>>> gradle 7 compatible version couldn't be found and dependencies were moved
>>>>>>> away from the removed configurations such as "compile" and "testCompile"
>>>>>>> (more on this below). If you experience issues during your development
>>>>>>> process that you suspect is due to the migration, feel free to reach out.
>>>>>>>
>>>>>>> For the removed configurations (boxes with light gray text), the
>>>>>>> gradle migration guide[2] suggested that existing usages of "compile" be
>>>>>>> replaced with "implementation" and "testCompile" with "testImplementation".
>>>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7
>>>>>>> forced the split of configurations used to declare dependencies (light
>>>>>>> green) and configurations that are consumed by tasks (blue gray). A new
>>>>>>> configuration called "testRuntimeMigration" was created for the purpose of
>>>>>>> migrating the widely used "testRuntime" configuration. The
>>>>>>> "testRuntimeConfiguration" contains the current modules test jar and
>>>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations
>>>>>>> effectively creating something similar to the "testRuntimeClasspath" which
>>>>>>> can be consumed by tasks and used to declare dependencies to other modules
>>>>>>> tests. This seems to be working at the moment but open to suggestions on
>>>>>>> how to re-organize this cleanly (e.g. should jar also add to
>>>>>>> "testRuntimeMigration").
>>>>>>>
>>>>>>> For the main source set:
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> For the test source set (forgive my paint skills):
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>>
>>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>>>>> 2:
>>>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>>>>
>>>>>>
Re: Gradle 7 migration
Posted by Robert Burke <ro...@frantil.com>.
As a non-OSX user, I can't tell you. I'll look into it tomorrow.
On Mon, Jan 3, 2022, 6:24 PM Reuven Lax <re...@google.com> wrote:
> Also xcun is installed on my machine, just not under
> Library/Developer/CommandLineTools/. Is there something about the new go
> version that's causing it to look in that directory?
>
> On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote:
>
>> I was running spotlessApply - which is pretty much a prerequisite for
>> submitting any code to Beam.
>>
>> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
>>
>>> Xcrun is news to me. Something in the go toolchain for that command I
>>> guess. I assume you might not have xcode tools installed. Eg.
>>> https://developer.apple.com/forums/thread/673827
>>>
>>> Were you running the :sdks:go:test target directly?
>>>
>>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>>>
>>>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
>>>> I've updated the go version, but I'm still getting the following error. Any
>>>> idea what I'm doing wrong?
>>>>
>>>> *> Configure project :sdks:go:test*
>>>>
>>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>>>
>>>> # runtime/cgo
>>>>
>>>> xcrun: error: invalid active developer path
>>>> (/Library/Developer/CommandLineTools), missing xcrun at:
>>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>>>
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>>
>>>> * Where:
>>>>
>>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>>>
>>>>
>>>> * What went wrong:
>>>>
>>>> A problem occurred evaluating project ':sdks:go:test'.
>>>>
>>>> > Could not create task ':sdks:go:test:goPrepare'.
>>>>
>>>> > Process 'command 'sh'' finished with non-zero exit value 2
>>>>
>>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com>
>>>> wrote:
>>>>
>>>>> Great graphs Luke!
>>>>>
>>>>> Related note: with this migration the project no longer uses the
>>>>> GoGradle plugin to build or test any Go source. They have been replaced
>>>>> with shell script that bootstrap to a set version of go. This is tracked
>>>>> in BEAM-12830 [1].
>>>>>
>>>>> This touches all portable builds as the project uses small Go programs
>>>>> for portable container bootstrap.
>>>>>
>>>>> The following are the consequences of this change and known issues:
>>>>>
>>>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary
>>>>> Go versions going forward.
>>>>> * Presently Nightly Snapshots are broken since the shared infra
>>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>>>> See that for the paired ticket to Infra for upgrading.
>>>>>
>>>>> * OSX users can't currently run the Go integration tests locally, due
>>>>> to the scripts not currently building both the local host platform version
>>>>> and the container required version of pipelines.
>>>>> * This is a small inconvenience as it only prevents using the gradle
>>>>> scripts, and not using beam by using Go directly.
>>>>>
>>>>> If there are any other issues related to the removal of GoGradle, or
>>>>> either of these limitations become urgent, please let me know so a fix can
>>>>> be expedited.
>>>>>
>>>>> Cheers,
>>>>> Robert Burke
>>>>> Beam Go Busybody
>>>>>
>>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>>>
>>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>>>
>>>>>> The migration to gradle 7[1] happened in the past two weeks. As part
>>>>>> of that migration many plugins had to be updated or replaced if a newer
>>>>>> gradle 7 compatible version couldn't be found and dependencies were moved
>>>>>> away from the removed configurations such as "compile" and "testCompile"
>>>>>> (more on this below). If you experience issues during your development
>>>>>> process that you suspect is due to the migration, feel free to reach out.
>>>>>>
>>>>>> For the removed configurations (boxes with light gray text), the
>>>>>> gradle migration guide[2] suggested that existing usages of "compile" be
>>>>>> replaced with "implementation" and "testCompile" with "testImplementation".
>>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7
>>>>>> forced the split of configurations used to declare dependencies (light
>>>>>> green) and configurations that are consumed by tasks (blue gray). A new
>>>>>> configuration called "testRuntimeMigration" was created for the purpose of
>>>>>> migrating the widely used "testRuntime" configuration. The
>>>>>> "testRuntimeConfiguration" contains the current modules test jar and
>>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations
>>>>>> effectively creating something similar to the "testRuntimeClasspath" which
>>>>>> can be consumed by tasks and used to declare dependencies to other modules
>>>>>> tests. This seems to be working at the moment but open to suggestions on
>>>>>> how to re-organize this cleanly (e.g. should jar also add to
>>>>>> "testRuntimeMigration").
>>>>>>
>>>>>> For the main source set:
>>>>>> [image: image.png]
>>>>>>
>>>>>> For the test source set (forgive my paint skills):
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>>>> 2:
>>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>>>
>>>>>
Re: Gradle 7 migration
Posted by Daniel Collins <dp...@google.com>.
My guess is your version of xcode is old? That's often the cause of such
errors. Try installing the newest full xcode version (I think there's an
internal download page for google employees with a version that's known to
work with internal tools) then run `sudo xcode-select -s
/Applications/XCode.app` again.
On Mon, Jan 3, 2022 at 9:24 PM Reuven Lax <re...@google.com> wrote:
> Also xcun is installed on my machine, just not under
> Library/Developer/CommandLineTools/. Is there something about the new go
> version that's causing it to look in that directory?
>
> On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote:
>
>> I was running spotlessApply - which is pretty much a prerequisite for
>> submitting any code to Beam.
>>
>> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
>>
>>> Xcrun is news to me. Something in the go toolchain for that command I
>>> guess. I assume you might not have xcode tools installed. Eg.
>>> https://developer.apple.com/forums/thread/673827
>>>
>>> Were you running the :sdks:go:test target directly?
>>>
>>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>>>
>>>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
>>>> I've updated the go version, but I'm still getting the following error. Any
>>>> idea what I'm doing wrong?
>>>>
>>>> *> Configure project :sdks:go:test*
>>>>
>>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>>>
>>>> # runtime/cgo
>>>>
>>>> xcrun: error: invalid active developer path
>>>> (/Library/Developer/CommandLineTools), missing xcrun at:
>>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>>>
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>>
>>>> * Where:
>>>>
>>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>>>
>>>>
>>>> * What went wrong:
>>>>
>>>> A problem occurred evaluating project ':sdks:go:test'.
>>>>
>>>> > Could not create task ':sdks:go:test:goPrepare'.
>>>>
>>>> > Process 'command 'sh'' finished with non-zero exit value 2
>>>>
>>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com>
>>>> wrote:
>>>>
>>>>> Great graphs Luke!
>>>>>
>>>>> Related note: with this migration the project no longer uses the
>>>>> GoGradle plugin to build or test any Go source. They have been replaced
>>>>> with shell script that bootstrap to a set version of go. This is tracked
>>>>> in BEAM-12830 [1].
>>>>>
>>>>> This touches all portable builds as the project uses small Go programs
>>>>> for portable container bootstrap.
>>>>>
>>>>> The following are the consequences of this change and known issues:
>>>>>
>>>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary
>>>>> Go versions going forward.
>>>>> * Presently Nightly Snapshots are broken since the shared infra
>>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>>>> See that for the paired ticket to Infra for upgrading.
>>>>>
>>>>> * OSX users can't currently run the Go integration tests locally, due
>>>>> to the scripts not currently building both the local host platform version
>>>>> and the container required version of pipelines.
>>>>> * This is a small inconvenience as it only prevents using the gradle
>>>>> scripts, and not using beam by using Go directly.
>>>>>
>>>>> If there are any other issues related to the removal of GoGradle, or
>>>>> either of these limitations become urgent, please let me know so a fix can
>>>>> be expedited.
>>>>>
>>>>> Cheers,
>>>>> Robert Burke
>>>>> Beam Go Busybody
>>>>>
>>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>>>
>>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>>>
>>>>>> The migration to gradle 7[1] happened in the past two weeks. As part
>>>>>> of that migration many plugins had to be updated or replaced if a newer
>>>>>> gradle 7 compatible version couldn't be found and dependencies were moved
>>>>>> away from the removed configurations such as "compile" and "testCompile"
>>>>>> (more on this below). If you experience issues during your development
>>>>>> process that you suspect is due to the migration, feel free to reach out.
>>>>>>
>>>>>> For the removed configurations (boxes with light gray text), the
>>>>>> gradle migration guide[2] suggested that existing usages of "compile" be
>>>>>> replaced with "implementation" and "testCompile" with "testImplementation".
>>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7
>>>>>> forced the split of configurations used to declare dependencies (light
>>>>>> green) and configurations that are consumed by tasks (blue gray). A new
>>>>>> configuration called "testRuntimeMigration" was created for the purpose of
>>>>>> migrating the widely used "testRuntime" configuration. The
>>>>>> "testRuntimeConfiguration" contains the current modules test jar and
>>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations
>>>>>> effectively creating something similar to the "testRuntimeClasspath" which
>>>>>> can be consumed by tasks and used to declare dependencies to other modules
>>>>>> tests. This seems to be working at the moment but open to suggestions on
>>>>>> how to re-organize this cleanly (e.g. should jar also add to
>>>>>> "testRuntimeMigration").
>>>>>>
>>>>>> For the main source set:
>>>>>> [image: image.png]
>>>>>>
>>>>>> For the test source set (forgive my paint skills):
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>>>> 2:
>>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>>>
>>>>>
Re: Gradle 7 migration
Posted by Reuven Lax <re...@google.com>.
Also xcun is installed on my machine, just not under
Library/Developer/CommandLineTools/. Is there something about the new go
version that's causing it to look in that directory?
On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote:
> I was running spotlessApply - which is pretty much a prerequisite for
> submitting any code to Beam.
>
> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
>
>> Xcrun is news to me. Something in the go toolchain for that command I
>> guess. I assume you might not have xcode tools installed. Eg.
>> https://developer.apple.com/forums/thread/673827
>>
>> Were you running the :sdks:go:test target directly?
>>
>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>>
>>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
>>> I've updated the go version, but I'm still getting the following error. Any
>>> idea what I'm doing wrong?
>>>
>>> *> Configure project :sdks:go:test*
>>>
>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>>
>>> # runtime/cgo
>>>
>>> xcrun: error: invalid active developer path
>>> (/Library/Developer/CommandLineTools), missing xcrun at:
>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>>
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>>
>>> * Where:
>>>
>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>>
>>>
>>> * What went wrong:
>>>
>>> A problem occurred evaluating project ':sdks:go:test'.
>>>
>>> > Could not create task ':sdks:go:test:goPrepare'.
>>>
>>> > Process 'command 'sh'' finished with non-zero exit value 2
>>>
>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com>
>>> wrote:
>>>
>>>> Great graphs Luke!
>>>>
>>>> Related note: with this migration the project no longer uses the
>>>> GoGradle plugin to build or test any Go source. They have been replaced
>>>> with shell script that bootstrap to a set version of go. This is tracked
>>>> in BEAM-12830 [1].
>>>>
>>>> This touches all portable builds as the project uses small Go programs
>>>> for portable container bootstrap.
>>>>
>>>> The following are the consequences of this change and known issues:
>>>>
>>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary
>>>> Go versions going forward.
>>>> * Presently Nightly Snapshots are broken since the shared infra
>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>>> See that for the paired ticket to Infra for upgrading.
>>>>
>>>> * OSX users can't currently run the Go integration tests locally, due
>>>> to the scripts not currently building both the local host platform version
>>>> and the container required version of pipelines.
>>>> * This is a small inconvenience as it only prevents using the gradle
>>>> scripts, and not using beam by using Go directly.
>>>>
>>>> If there are any other issues related to the removal of GoGradle, or
>>>> either of these limitations become urgent, please let me know so a fix can
>>>> be expedited.
>>>>
>>>> Cheers,
>>>> Robert Burke
>>>> Beam Go Busybody
>>>>
>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>>
>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>>
>>>>
>>>>
>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>>
>>>>> The migration to gradle 7[1] happened in the past two weeks. As part
>>>>> of that migration many plugins had to be updated or replaced if a newer
>>>>> gradle 7 compatible version couldn't be found and dependencies were moved
>>>>> away from the removed configurations such as "compile" and "testCompile"
>>>>> (more on this below). If you experience issues during your development
>>>>> process that you suspect is due to the migration, feel free to reach out.
>>>>>
>>>>> For the removed configurations (boxes with light gray text), the
>>>>> gradle migration guide[2] suggested that existing usages of "compile" be
>>>>> replaced with "implementation" and "testCompile" with "testImplementation".
>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7
>>>>> forced the split of configurations used to declare dependencies (light
>>>>> green) and configurations that are consumed by tasks (blue gray). A new
>>>>> configuration called "testRuntimeMigration" was created for the purpose of
>>>>> migrating the widely used "testRuntime" configuration. The
>>>>> "testRuntimeConfiguration" contains the current modules test jar and
>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations
>>>>> effectively creating something similar to the "testRuntimeClasspath" which
>>>>> can be consumed by tasks and used to declare dependencies to other modules
>>>>> tests. This seems to be working at the moment but open to suggestions on
>>>>> how to re-organize this cleanly (e.g. should jar also add to
>>>>> "testRuntimeMigration").
>>>>>
>>>>> For the main source set:
>>>>> [image: image.png]
>>>>>
>>>>> For the test source set (forgive my paint skills):
>>>>> [image: image.png]
>>>>>
>>>>>
>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>>> 2:
>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>>
>>>>
Re: Gradle 7 migration
Posted by Reuven Lax <re...@google.com>.
I was running spotlessApply - which is pretty much a prerequisite for
submitting any code to Beam.
On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <ro...@frantil.com> wrote:
> Xcrun is news to me. Something in the go toolchain for that command I
> guess. I assume you might not have xcode tools installed. Eg.
> https://developer.apple.com/forums/thread/673827
>
> Were you running the :sdks:go:test target directly?
>
> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
>
>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
>> I've updated the go version, but I'm still getting the following error. Any
>> idea what I'm doing wrong?
>>
>> *> Configure project :sdks:go:test*
>>
>> System Go installation: /usr/local/go/bin/go is go version go1.16.12
>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>>
>> # runtime/cgo
>>
>> xcrun: error: invalid active developer path
>> (/Library/Developer/CommandLineTools), missing xcrun at:
>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>
>>
>> FAILURE: Build failed with an exception.
>>
>>
>> * Where:
>>
>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>>
>>
>> * What went wrong:
>>
>> A problem occurred evaluating project ':sdks:go:test'.
>>
>> > Could not create task ':sdks:go:test:goPrepare'.
>>
>> > Process 'command 'sh'' finished with non-zero exit value 2
>>
>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com> wrote:
>>
>>> Great graphs Luke!
>>>
>>> Related note: with this migration the project no longer uses the
>>> GoGradle plugin to build or test any Go source. They have been replaced
>>> with shell script that bootstrap to a set version of go. This is tracked
>>> in BEAM-12830 [1].
>>>
>>> This touches all portable builds as the project uses small Go programs
>>> for portable container bootstrap.
>>>
>>> The following are the consequences of this change and known issues:
>>>
>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary Go
>>> versions going forward.
>>> * Presently Nightly Snapshots are broken since the shared infra
>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2].
>>> See that for the paired ticket to Infra for upgrading.
>>>
>>> * OSX users can't currently run the Go integration tests locally, due to
>>> the scripts not currently building both the local host platform version and
>>> the container required version of pipelines.
>>> * This is a small inconvenience as it only prevents using the gradle
>>> scripts, and not using beam by using Go directly.
>>>
>>> If there are any other issues related to the removal of GoGradle, or
>>> either of these limitations become urgent, please let me know so a fix can
>>> be expedited.
>>>
>>> Cheers,
>>> Robert Burke
>>> Beam Go Busybody
>>>
>>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>>
>>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>>
>>>
>>>
>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>>
>>>> The migration to gradle 7[1] happened in the past two weeks. As part of
>>>> that migration many plugins had to be updated or replaced if a newer gradle
>>>> 7 compatible version couldn't be found and dependencies were moved away
>>>> from the removed configurations such as "compile" and "testCompile" (more
>>>> on this below). If you experience issues during your development process
>>>> that you suspect is due to the migration, feel free to reach out.
>>>>
>>>> For the removed configurations (boxes with light gray text), the gradle
>>>> migration guide[2] suggested that existing usages of "compile" be replaced
>>>> with "implementation" and "testCompile" with "testImplementation". Usages
>>>> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
>>>> the split of configurations used to declare dependencies (light green) and
>>>> configurations that are consumed by tasks (blue gray). A new configuration
>>>> called "testRuntimeMigration" was created for the purpose of migrating the
>>>> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
>>>> contains the current modules test jar and extends the "testRuntimeOnly" and
>>>> "testImplementation" configurations effectively creating something similar
>>>> to the "testRuntimeClasspath" which can be consumed by tasks and used to
>>>> declare dependencies to other modules tests. This seems to be working at
>>>> the moment but open to suggestions on how to re-organize this cleanly (e.g.
>>>> should jar also add to "testRuntimeMigration").
>>>>
>>>> For the main source set:
>>>> [image: image.png]
>>>>
>>>> For the test source set (forgive my paint skills):
>>>> [image: image.png]
>>>>
>>>>
>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>>> 2:
>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>>
>>>
Re: Gradle 7 migration
Posted by Robert Burke <ro...@frantil.com>.
Xcrun is news to me. Something in the go toolchain for that command I
guess. I assume you might not have xcode tools installed. Eg.
https://developer.apple.com/forums/thread/673827
Were you running the :sdks:go:test target directly?
On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote:
> I am trying to run ./gradlew spotlessApply, and I'm getting go errors.
> I've updated the go version, but I'm still getting the following error. Any
> idea what I'm doing wrong?
>
> *> Configure project :sdks:go:test*
>
> System Go installation: /usr/local/go/bin/go is go version go1.16.12
> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
>
> # runtime/cgo
>
> xcrun: error: invalid active developer path
> (/Library/Developer/CommandLineTools), missing xcrun at:
> /Library/Developer/CommandLineTools/usr/bin/xcrun
>
>
> FAILURE: Build failed with an exception.
>
>
> * Where:
>
> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
>
>
> * What went wrong:
>
> A problem occurred evaluating project ':sdks:go:test'.
>
> > Could not create task ':sdks:go:test:goPrepare'.
>
> > Process 'command 'sh'' finished with non-zero exit value 2
>
> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com> wrote:
>
>> Great graphs Luke!
>>
>> Related note: with this migration the project no longer uses the GoGradle
>> plugin to build or test any Go source. They have been replaced with shell
>> script that bootstrap to a set version of go. This is tracked in
>> BEAM-12830 [1].
>>
>> This touches all portable builds as the project uses small Go programs
>> for portable container bootstrap.
>>
>> The following are the consequences of this change and known issues:
>>
>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary Go
>> versions going forward.
>> * Presently Nightly Snapshots are broken since the shared infra machine
>> is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2]. See that
>> for the paired ticket to Infra for upgrading.
>>
>> * OSX users can't currently run the Go integration tests locally, due to
>> the scripts not currently building both the local host platform version and
>> the container required version of pipelines.
>> * This is a small inconvenience as it only prevents using the gradle
>> scripts, and not using beam by using Go directly.
>>
>> If there are any other issues related to the removal of GoGradle, or
>> either of these limitations become urgent, please let me know so a fix can
>> be expedited.
>>
>> Cheers,
>> Robert Burke
>> Beam Go Busybody
>>
>> 1: https://issues.apache.org/jira/browse/BEAM-12830
>>
>> 2: https://issues.apache.org/jira/browse/BEAM-13540
>>
>>
>>
>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>>
>>> The migration to gradle 7[1] happened in the past two weeks. As part of
>>> that migration many plugins had to be updated or replaced if a newer gradle
>>> 7 compatible version couldn't be found and dependencies were moved away
>>> from the removed configurations such as "compile" and "testCompile" (more
>>> on this below). If you experience issues during your development process
>>> that you suspect is due to the migration, feel free to reach out.
>>>
>>> For the removed configurations (boxes with light gray text), the gradle
>>> migration guide[2] suggested that existing usages of "compile" be replaced
>>> with "implementation" and "testCompile" with "testImplementation". Usages
>>> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
>>> the split of configurations used to declare dependencies (light green) and
>>> configurations that are consumed by tasks (blue gray). A new configuration
>>> called "testRuntimeMigration" was created for the purpose of migrating the
>>> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
>>> contains the current modules test jar and extends the "testRuntimeOnly" and
>>> "testImplementation" configurations effectively creating something similar
>>> to the "testRuntimeClasspath" which can be consumed by tasks and used to
>>> declare dependencies to other modules tests. This seems to be working at
>>> the moment but open to suggestions on how to re-organize this cleanly (e.g.
>>> should jar also add to "testRuntimeMigration").
>>>
>>> For the main source set:
>>> [image: image.png]
>>>
>>> For the test source set (forgive my paint skills):
>>> [image: image.png]
>>>
>>>
>>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>>> 2:
>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>>
>>
Re: Gradle 7 migration
Posted by Reuven Lax <re...@google.com>.
I am trying to run ./gradlew spotlessApply, and I'm getting go errors. I've
updated the go version, but I'm still getting the following error. Any idea
what I'm doing wrong?
*> Configure project :sdks:go:test*
System Go installation: /usr/local/go/bin/go is go version go1.16.12
darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12
# runtime/cgo
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
FAILURE: Build failed with an exception.
* Where:
Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20
* What went wrong:
A problem occurred evaluating project ':sdks:go:test'.
> Could not create task ':sdks:go:test:goPrepare'.
> Process 'command 'sh'' finished with non-zero exit value 2
On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <ro...@frantil.com> wrote:
> Great graphs Luke!
>
> Related note: with this migration the project no longer uses the GoGradle
> plugin to build or test any Go source. They have been replaced with shell
> script that bootstrap to a set version of go. This is tracked in
> BEAM-12830 [1].
>
> This touches all portable builds as the project uses small Go programs for
> portable container bootstrap.
>
> The following are the consequences of this change and known issues:
>
> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary Go
> versions going forward.
> * Presently Nightly Snapshots are broken since the shared infra machine
> is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2]. See that
> for the paired ticket to Infra for upgrading.
>
> * OSX users can't currently run the Go integration tests locally, due to
> the scripts not currently building both the local host platform version and
> the container required version of pipelines.
> * This is a small inconvenience as it only prevents using the gradle
> scripts, and not using beam by using Go directly.
>
> If there are any other issues related to the removal of GoGradle, or
> either of these limitations become urgent, please let me know so a fix can
> be expedited.
>
> Cheers,
> Robert Burke
> Beam Go Busybody
>
> 1: https://issues.apache.org/jira/browse/BEAM-12830
>
> 2: https://issues.apache.org/jira/browse/BEAM-13540
>
>
>
> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
>
>> The migration to gradle 7[1] happened in the past two weeks. As part of
>> that migration many plugins had to be updated or replaced if a newer gradle
>> 7 compatible version couldn't be found and dependencies were moved away
>> from the removed configurations such as "compile" and "testCompile" (more
>> on this below). If you experience issues during your development process
>> that you suspect is due to the migration, feel free to reach out.
>>
>> For the removed configurations (boxes with light gray text), the gradle
>> migration guide[2] suggested that existing usages of "compile" be replaced
>> with "implementation" and "testCompile" with "testImplementation". Usages
>> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
>> the split of configurations used to declare dependencies (light green) and
>> configurations that are consumed by tasks (blue gray). A new configuration
>> called "testRuntimeMigration" was created for the purpose of migrating the
>> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
>> contains the current modules test jar and extends the "testRuntimeOnly" and
>> "testImplementation" configurations effectively creating something similar
>> to the "testRuntimeClasspath" which can be consumed by tasks and used to
>> declare dependencies to other modules tests. This seems to be working at
>> the moment but open to suggestions on how to re-organize this cleanly (e.g.
>> should jar also add to "testRuntimeMigration").
>>
>> For the main source set:
>> [image: image.png]
>>
>> For the test source set (forgive my paint skills):
>> [image: image.png]
>>
>>
>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>> 2:
>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>
>
Re: Gradle 7 migration
Posted by Robert Burke <ro...@frantil.com>.
Great graphs Luke!
Related note: with this migration the project no longer uses the GoGradle
plugin to build or test any Go source. They have been replaced with shell
script that bootstrap to a set version of go. This is tracked in
BEAM-12830 [1].
This touches all portable builds as the project uses small Go programs for
portable container bootstrap.
The following are the consequences of this change and known issues:
* The project requires a minimum of Go 1.16 to bootstrap to arbitrary Go
versions going forward.
* Presently Nightly Snapshots are broken since the shared infra machine
is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2]. See that
for the paired ticket to Infra for upgrading.
* OSX users can't currently run the Go integration tests locally, due to
the scripts not currently building both the local host platform version and
the container required version of pipelines.
* This is a small inconvenience as it only prevents using the gradle
scripts, and not using beam by using Go directly.
If there are any other issues related to the removal of GoGradle, or either
of these limitations become urgent, please let me know so a fix can be
expedited.
Cheers,
Robert Burke
Beam Go Busybody
1: https://issues.apache.org/jira/browse/BEAM-12830
2: https://issues.apache.org/jira/browse/BEAM-13540
On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote:
> The migration to gradle 7[1] happened in the past two weeks. As part of
> that migration many plugins had to be updated or replaced if a newer gradle
> 7 compatible version couldn't be found and dependencies were moved away
> from the removed configurations such as "compile" and "testCompile" (more
> on this below). If you experience issues during your development process
> that you suspect is due to the migration, feel free to reach out.
>
> For the removed configurations (boxes with light gray text), the gradle
> migration guide[2] suggested that existing usages of "compile" be replaced
> with "implementation" and "testCompile" with "testImplementation". Usages
> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
> the split of configurations used to declare dependencies (light green) and
> configurations that are consumed by tasks (blue gray). A new configuration
> called "testRuntimeMigration" was created for the purpose of migrating the
> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
> contains the current modules test jar and extends the "testRuntimeOnly" and
> "testImplementation" configurations effectively creating something similar
> to the "testRuntimeClasspath" which can be consumed by tasks and used to
> declare dependencies to other modules tests. This seems to be working at
> the moment but open to suggestions on how to re-organize this cleanly (e.g.
> should jar also add to "testRuntimeMigration").
>
> For the main source set:
> [image: image.png]
>
> For the test source set (forgive my paint skills):
> [image: image.png]
>
>
> 1: https://issues.apache.org/jira/browse/BEAM-13430
> 2:
> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>
Re: Gradle 7 migration
Posted by Luke Cwik <lc...@google.com>.
Yes, I updated the wiki in the few places mentioned and added the
configurations map to the wiki as well. I suspect it may change as we
resolve the discussion around the propdeps plugin.
On Thu, Dec 30, 2021 at 10:14 AM Robert Bradshaw <ro...@google.com>
wrote:
> Thank you, Luke! Have you had a chance to update the docs/wiki as well?
>
> On Thu, Dec 30, 2021 at 9:45 AM Luke Cwik <lc...@google.com> wrote:
>
>> The migration to gradle 7[1] happened in the past two weeks. As part of
>> that migration many plugins had to be updated or replaced if a newer gradle
>> 7 compatible version couldn't be found and dependencies were moved away
>> from the removed configurations such as "compile" and "testCompile" (more
>> on this below). If you experience issues during your development process
>> that you suspect is due to the migration, feel free to reach out.
>>
>> For the removed configurations (boxes with light gray text), the gradle
>> migration guide[2] suggested that existing usages of "compile" be replaced
>> with "implementation" and "testCompile" with "testImplementation". Usages
>> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
>> the split of configurations used to declare dependencies (light green) and
>> configurations that are consumed by tasks (blue gray). A new configuration
>> called "testRuntimeMigration" was created for the purpose of migrating the
>> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
>> contains the current modules test jar and extends the "testRuntimeOnly" and
>> "testImplementation" configurations effectively creating something similar
>> to the "testRuntimeClasspath" which can be consumed by tasks and used to
>> declare dependencies to other modules tests. This seems to be working at
>> the moment but open to suggestions on how to re-organize this cleanly (e.g.
>> should jar also add to "testRuntimeMigration").
>>
>> For the main source set:
>> [image: image.png]
>>
>> For the test source set (forgive my paint skills):
>> [image: image.png]
>>
>>
>> 1: https://issues.apache.org/jira/browse/BEAM-13430
>> 2:
>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>>
>
Re: Gradle 7 migration
Posted by Robert Bradshaw <ro...@google.com>.
Thank you, Luke! Have you had a chance to update the docs/wiki as well?
On Thu, Dec 30, 2021 at 9:45 AM Luke Cwik <lc...@google.com> wrote:
> The migration to gradle 7[1] happened in the past two weeks. As part of
> that migration many plugins had to be updated or replaced if a newer gradle
> 7 compatible version couldn't be found and dependencies were moved away
> from the removed configurations such as "compile" and "testCompile" (more
> on this below). If you experience issues during your development process
> that you suspect is due to the migration, feel free to reach out.
>
> For the removed configurations (boxes with light gray text), the gradle
> migration guide[2] suggested that existing usages of "compile" be replaced
> with "implementation" and "testCompile" with "testImplementation". Usages
> of "runtime" and "testRuntime" are more complicated since Gradle 7 forced
> the split of configurations used to declare dependencies (light green) and
> configurations that are consumed by tasks (blue gray). A new configuration
> called "testRuntimeMigration" was created for the purpose of migrating the
> widely used "testRuntime" configuration. The "testRuntimeConfiguration"
> contains the current modules test jar and extends the "testRuntimeOnly" and
> "testImplementation" configurations effectively creating something similar
> to the "testRuntimeClasspath" which can be consumed by tasks and used to
> declare dependencies to other modules tests. This seems to be working at
> the moment but open to suggestions on how to re-organize this cleanly (e.g.
> should jar also add to "testRuntimeMigration").
>
> For the main source set:
> [image: image.png]
>
> For the test source set (forgive my paint skills):
> [image: image.png]
>
>
> 1: https://issues.apache.org/jira/browse/BEAM-13430
> 2:
> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal
>