[apksigner] Remove AdditionalProperties on java-source-utils.csproj #7157
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
description TBD. It'll be long.
jonpryor
changed the title
Contributor
Author
|
Further investigation suggests that this isn't the fix I was hoping for. My hope was that with this change, Compare to the I'm still missing something; not sure what yet. |
Contributor
Author
|
Through the glory is that is (1) the MSBuild Structured Log Viewer (which I really should use more often) and (2) the "target path window" at the bottom of the Windows MSBuild Structured Log Viewer app -- which quite nicely answers the question "how did I get here?" -- I now see why
Thus, the two |
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Jul 7, 2022
Context: dotnet/android#7157 Ever since commit 69e1b80, `java-source-utils.csproj` used the `$(TargetFrameworks)` plural form, even though it only specified a single framework. I don't remember underlying reason for this, other than "that's what I needed for it to build," which might have been because the `_BuildJava` target was "wrong". This arrangement was "fine", until dotnet/android@2197a459, after which the xamarin-android/main CI builds started behaving "weird": frequently `make all-tests` would fail, because `make jenkins` would produce an invalid or corrupt `java-source-utils.jar`, *apparently* because it was attempting to *concurrently build* `java-source-utils.csproj` (?!). One of these concurrent builds *appeared* to be an "outer build" from `Xamarin.Android.sln`, while another one appeared to be an "inner build" via `apksigner.csproj` and `%(ProjectReference.AdditionalProperties)`: 17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): 17:53:44.526 59:11>Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist. … 17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it): Task "MSBuild" (TaskId:1099) Task Parameter:BuildInParallel=True (TaskId:1099) Task Parameter:Targets=Build (TaskId:1099) Task Parameter: Projects= java-source-utils.csproj AdditionalProperties=TargetFramework=net7.0 (TaskId:1099) Additional Properties for project "java-source-utils.csproj": (TaskId:1099) TargetFramework=net7.0 (TaskId:1099) … 17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist. … 17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490) We attempted to fix this by removing `%(ProjectReference.AdditionalProperties)`, which only slightly changed things: the "outer build via `Xamarin.Android.sln`" build was removed, but we instead saw a scenario in which `java-source-utils.csproj` was built "once", and as part of that build the "outer" and "inner" builds were run concurrently. A commonality here is `$(TargetFrameworks)` requires "outer" and "inner" builds, and that is a complication that we should remove. Update `java-source-utils.csproj` so that `$(TargetFramework)` is used, not `$(TargetFrameworks)`. Update the `_BuildJava` target so that it runs before the `GetCopyToOutputDirectoryItems` target. This is consistent with how the [`_BuildGradle` target in `apksigner.csproj`][0] works. Without this change -- and the removal of the empty `Build` target -- the `java-source-utils.csproj` build didn't behave correctly (`gradlew` wasn't run). Hopefully once only a single `$(TargetFramework)` is built, we will be able to restore build system sanity to xamarin-android. [0]: https://github.com/xamarin/xamarin-android/blob/c537dd28c30f482f365ef756214be35aa1553da2/src/apksigner/apksigner.targets#L3-L13
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Jul 7, 2022
Context: dotnet/android#7157 Ever since commit 69e1b80, `java-source-utils.csproj` used the `$(TargetFrameworks)` plural form, even though it only specified a single framework. I don't remember underlying reason for this, other than "that's what I needed for it to build," which might have been because the `_BuildJava` target was "wrong". This arrangement was "fine", until dotnet/android@2197a459, after which the xamarin-android/main CI builds started behaving "weird": frequently `make all-tests` would fail, because `make jenkins` would produce an invalid or corrupt `java-source-utils.jar`, *apparently* because it was attempting to *concurrently build* `java-source-utils.csproj` (?!). One of these concurrent builds *appeared* to be an "outer build" from `Xamarin.Android.sln`, while another one appeared to be an "inner build" via `apksigner.csproj` and `%(ProjectReference.AdditionalProperties)`: 17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): 17:53:44.526 59:11>Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist. … 17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it): Task "MSBuild" (TaskId:1099) Task Parameter:BuildInParallel=True (TaskId:1099) Task Parameter:Targets=Build (TaskId:1099) Task Parameter: Projects= java-source-utils.csproj AdditionalProperties=TargetFramework=net7.0 (TaskId:1099) Additional Properties for project "java-source-utils.csproj": (TaskId:1099) TargetFramework=net7.0 (TaskId:1099) … 17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist. … 17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490) We attempted to fix this by removing `%(ProjectReference.AdditionalProperties)`, which only slightly changed things: the "outer build via `Xamarin.Android.sln`" build was removed, but we instead saw a scenario in which `java-source-utils.csproj` was built "once", and as part of that build the "outer" and "inner" builds were run concurrently. A commonality here is `$(TargetFrameworks)` requires "outer" and "inner" builds, and that is a complication that we should remove. Update `java-source-utils.csproj` so that `$(TargetFramework)` is used, not `$(TargetFrameworks)`. Update the `_BuildJava` target so that it runs before the `GetCopyToOutputDirectoryItems` target. This is consistent with how the [`_BuildGradle` target in `apksigner.csproj`][0] works. Without this change -- and the removal of the empty `Build` target -- the `java-source-utils.csproj` build didn't behave correctly (`gradlew` wasn't run). Unfortunately, this seemingly simple change hits a little "snag": `Directory.Build.props` is imported [very early][1]: > *Directory.Build.props* is imported very early in > *Microsoft.Common.props*, and properties defined later are > unavailable to it. "Properties defined later are unavailable to it." Properties such as `$(TargetFramework)`. Which means that every property we have in `Directory.Build.props` which "depend" on `$(TargetFramework)` *are not **actually** usable*. They've only *appeared* to work because they would default to "classic" paths, but as soon as you try to build with `$(TargetFramework)`=net7.0 -- as was attempted with `java-source-utils.csproj`, and previously with `Java.Base.csproj` (bc5bcf4) -- you'll find that the "wrong" directories are used for `$(OutputPath)`. This has been a long-standing deficiency in my MSBuild understanding. Fix this by adding a new `TargetFrameworkDependentValues.props` file, and `<Import/>`ing this file in *every* `.csproj` which sets MSBuild properties with values dependent upon `$(TargetFramework)` *before* those properties are set. Old and busted: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> New hawtness: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> </PropertyGroup> <Import Project="..\..\TargetFrameworkDependentValues.props" /> <PropertyGroup> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> [0]: https://github.com/xamarin/xamarin-android/blob/c537dd28c30f482f365ef756214be35aa1553da2/src/apksigner/apksigner.targets#L3-L13 [1]: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#import-order
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Jul 7, 2022
Context: dotnet/android#7157 Ever since commit 69e1b80, `java-source-utils.csproj` used the `$(TargetFrameworks)` plural form, even though it only specified a single framework. I don't remember underlying reason for this, other than "that's what I needed for it to build," which might have been because the `_BuildJava` target was "wrong". This arrangement was "fine", until dotnet/android@2197a459, after which the xamarin-android/main CI builds started behaving "weird": frequently `make all-tests` would fail, because `make jenkins` would produce an invalid or corrupt `java-source-utils.jar`, *apparently* because it was attempting to *concurrently build* `java-source-utils.csproj` (?!). One of these concurrent builds *appeared* to be an "outer build" from `Xamarin.Android.sln`, while another one appeared to be an "inner build" via `apksigner.csproj` and `%(ProjectReference.AdditionalProperties)`: 17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): 17:53:44.526 59:11>Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist. … 17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it): Task "MSBuild" (TaskId:1099) Task Parameter:BuildInParallel=True (TaskId:1099) Task Parameter:Targets=Build (TaskId:1099) Task Parameter: Projects= java-source-utils.csproj AdditionalProperties=TargetFramework=net7.0 (TaskId:1099) Additional Properties for project "java-source-utils.csproj": (TaskId:1099) TargetFramework=net7.0 (TaskId:1099) … 17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist. … 17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490) We attempted to fix this by removing `%(ProjectReference.AdditionalProperties)`, which only slightly changed things: the "outer build via `Xamarin.Android.sln`" build was removed, but we instead saw a scenario in which `java-source-utils.csproj` was built "once", and as part of that build the "outer" and "inner" builds were run concurrently. A commonality here is `$(TargetFrameworks)` requires "outer" and "inner" builds, and that is a complication that we should remove. Update `java-source-utils.csproj` so that `$(TargetFramework)` is used, not `$(TargetFrameworks)`. Update the `_BuildJava` target so that it runs before the `GetCopyToOutputDirectoryItems` target. This is consistent with how the [`_BuildGradle` target in `apksigner.csproj`][0] works. Without this change -- and the removal of the empty `Build` target -- the `java-source-utils.csproj` build didn't behave correctly (`gradlew` wasn't run). Unfortunately, this seemingly simple change hits a little "snag": `Directory.Build.props` is imported [very early][1]: > *Directory.Build.props* is imported very early in > *Microsoft.Common.props*, and properties defined later are > unavailable to it. "Properties defined later are unavailable to it." Properties such as `$(TargetFramework)`. Which means that every property we have in `Directory.Build.props` which "depend" on `$(TargetFramework)` *are not **actually** usable*. They've only *appeared* to work because they would default to "classic" paths, but as soon as you try to build with `$(TargetFramework)`=net7.0 -- as was attempted with `java-source-utils.csproj`, and previously with `Java.Base.csproj` (bc5bcf4) -- you'll find that the "wrong" directories are used for `$(OutputPath)`. This has been a long-standing deficiency in my MSBuild understanding. Fix this by adding a new `TargetFrameworkDependentValues.props` file, and `<Import/>`ing this file in *every* `.csproj` which sets MSBuild properties with values dependent upon `$(TargetFramework)` *before* those properties are set. Old and busted: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> New hawtness: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> </PropertyGroup> <Import Project="..\..\TargetFrameworkDependentValues.props" /> <PropertyGroup> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> [0]: https://github.com/xamarin/xamarin-android/blob/c537dd28c30f482f365ef756214be35aa1553da2/src/apksigner/apksigner.targets#L3-L13 [1]: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#import-order
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Jul 7, 2022
Context: dotnet/android#7157 Ever since commit 69e1b80, `java-source-utils.csproj` used the `$(TargetFrameworks)` plural form, even though it only specified a single framework. I don't remember underlying reason for this, other than "that's what I needed for it to build," which might have been because the `_BuildJava` target was "wrong". This arrangement was "fine", until dotnet/android@2197a459, after which the xamarin-android/main CI builds started behaving "weird": frequently `make all-tests` would fail, because `make jenkins` would produce an invalid or corrupt `java-source-utils.jar`, *apparently* because it was attempting to *concurrently build* `java-source-utils.csproj` (?!). One of these concurrent builds *appeared* to be an "outer build" from `Xamarin.Android.sln`, while another one appeared to be an "inner build" via `apksigner.csproj` and `%(ProjectReference.AdditionalProperties)`: 17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): 17:53:44.526 59:11>Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist. … 17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it): Task "MSBuild" (TaskId:1099) Task Parameter:BuildInParallel=True (TaskId:1099) Task Parameter:Targets=Build (TaskId:1099) Task Parameter: Projects= java-source-utils.csproj AdditionalProperties=TargetFramework=net7.0 (TaskId:1099) Additional Properties for project "java-source-utils.csproj": (TaskId:1099) TargetFramework=net7.0 (TaskId:1099) … 17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist. … 17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490) We attempted to fix this by removing `%(ProjectReference.AdditionalProperties)`, which only slightly changed things: the "outer build via `Xamarin.Android.sln`" build was removed, but we instead saw a scenario in which `java-source-utils.csproj` was built "once", and as part of that build the "outer" and "inner" builds were run concurrently. A commonality here is `$(TargetFrameworks)` requires "outer" and "inner" builds, and that is a complication that we should remove. Update `java-source-utils.csproj` so that `$(TargetFramework)` is used, not `$(TargetFrameworks)`. Update the `_BuildJava` target so that it runs before the `GetCopyToOutputDirectoryItems` target. This is consistent with how the [`_BuildGradle` target in `apksigner.csproj`][0] works. Without this change -- and the removal of the empty `Build` target -- the `java-source-utils.csproj` build didn't behave correctly (`gradlew` wasn't run). Unfortunately, this seemingly simple change hits a little "snag": `Directory.Build.props` is imported [very early][1]: > *Directory.Build.props* is imported very early in > *Microsoft.Common.props*, and properties defined later are > unavailable to it. "Properties defined later are unavailable to it." Properties such as `$(TargetFramework)`. Which means that every property we have in `Directory.Build.props` which "depend" on `$(TargetFramework)` *are not **actually** usable*. They've only *appeared* to work because they would default to "classic" paths, but as soon as you try to build with `$(TargetFramework)`=net7.0 -- as was attempted with `java-source-utils.csproj`, and previously with `Java.Base.csproj` (bc5bcf4) -- you'll find that the "wrong" directories are used for `$(OutputPath)`. This has been a long-standing deficiency in my MSBuild understanding. Fix this by adding a new `TargetFrameworkDependentValues.props` file, and `<Import/>`ing this file in *every* `.csproj` which sets MSBuild properties with values dependent upon `$(TargetFramework)` *before* those properties are set. Old and busted: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> New hawtness: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> </PropertyGroup> <Import Project="..\..\TargetFrameworkDependentValues.props" /> <PropertyGroup> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> [0]: https://github.com/xamarin/xamarin-android/blob/c537dd28c30f482f365ef756214be35aa1553da2/src/apksigner/apksigner.targets#L3-L13 [1]: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#import-order
jonpryor
force-pushed
the
jonp-fix-jsu-build
branch
from
c32dba4 to
52eacd0
Compare
Contributor
Author
|
PR dotnet/java-interop#1007 changes |
jonpryor
commented
Jul 8, 2022
| <!-- There isn't an actual dependency here, but we can only build one 'gradlew' project | ||
| at a time, and adding <ProjectReference> between them ensures they run sequentially. --> | ||
| <ProjectReference Include="..\..\external\Java.Interop\tools\java-source-utils\java-source-utils.csproj" ReferenceOutputAssembly="False" SkipGetTargetFrameworkProperties="True" AdditionalProperties="TargetFramework=$(DotNetTargetFramework)" /> | ||
| <ProjectReference Include="..\..\external\Java.Interop\tools\java-source-utils\java-source-utils.csproj" ReferenceOutputAssembly="False" /> |
Contributor
Author
There was a problem hiding this comment.
jonpryor
commented
Jul 8, 2022
.gitmodules
Outdated
| path = external/Java.Interop | ||
| url = https://github.com/xamarin/java.interop.git | ||
| branch = main | ||
| url = https://github.com/jonpryor/java.interop.git |
Contributor
Author
There was a problem hiding this comment.
These changes clearly need to be reverted before we can merge, and dotnet/java-interop#1007 needs to be merged, but otherwise…
jonpryor
added a commit
to dotnet/java-interop
that referenced
this pull request
Jul 8, 2022
Context: dotnet/android#7157 Ever since commit 69e1b80, `java-source-utils.csproj` used the `$(TargetFrameworks)` plural form, even though it only specified a single framework. I don't remember underlying reason for this, other than "that's what I needed for it to build," which might have been because the `_BuildJava` target was "wrong". This arrangement was "fine", until dotnet/android@2197a459, after which the xamarin-android/main CI builds started behaving "weird": frequently `make all-tests` would fail, because `make jenkins` would produce an invalid or corrupt `java-source-utils.jar`, *apparently* because it was attempting to *concurrently build* `java-source-utils.csproj` (?!). One of these concurrent builds *appeared* to be an "outer build" from `Xamarin.Android.sln`, while another one appeared to be an "inner build" via `apksigner.csproj` and `%(ProjectReference.AdditionalProperties)`: 17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): 17:53:44.526 59:11>Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist. … 17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it): Task "MSBuild" (TaskId:1099) Task Parameter:BuildInParallel=True (TaskId:1099) Task Parameter:Targets=Build (TaskId:1099) Task Parameter: Projects= java-source-utils.csproj AdditionalProperties=TargetFramework=net7.0 (TaskId:1099) Additional Properties for project "java-source-utils.csproj": (TaskId:1099) TargetFramework=net7.0 (TaskId:1099) … 17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point): Building target "_BuildJava" completely. Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist. … 17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490) We attempted to fix this by removing `%(ProjectReference.AdditionalProperties)`, which only slightly changed things: the "outer build via `Xamarin.Android.sln`" build was removed, but we instead saw a scenario in which `java-source-utils.csproj` was built "once", and as part of that build the "outer" and "inner" builds were run concurrently. A commonality here is `$(TargetFrameworks)` requires "outer" and "inner" builds, and that is a complication that we should remove. Update `java-source-utils.csproj` so that singular `$(TargetFramework)` is used, not plural `$(TargetFrameworks)`. Update the `_BuildJava` target so that it runs before the `GetCopyToOutputDirectoryItems` target. This is consistent with how the [`_BuildGradle` target in `apksigner.csproj`][0] works. Without this change -- and the removal of the empty `Build` target -- the `java-source-utils.csproj` build didn't behave correctly (`gradlew` wasn't run). Unfortunately, this seemingly simple change hits a little "snag": `Directory.Build.props` is imported [very early][1]: > *Directory.Build.props* is imported very early in > *Microsoft.Common.props*, and properties defined later are > unavailable to it. "Properties defined later are unavailable to it." Properties such as `$(TargetFramework)`. Which means that every property we have in `Directory.Build.props` which "depends" on `$(TargetFramework)` *are not **actually** usable*. They've only *appeared* to work because they would default to "classic" paths, but as soon as you try to build with `$(TargetFramework)`=net7.0 -- as was attempted with `java-source-utils.csproj`, and previously with `Java.Base.csproj` (bc5bcf4) -- you'll find that the "wrong" directories are used for `$(OutputPath)`. This has been a long-standing deficiency in my MSBuild understanding. Fix this by adding a new `TargetFrameworkDependentValues.props` file, and `<Import/>`ing this file in *every* `.csproj` which uses MSBuild properties with values dependent upon `$(TargetFramework)` *before* those properties are set. Old and busted: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> New hawtness: <PropertyGroup> <TargetFramework>net7.0</TargetFramework> </PropertyGroup> <Import Project="..\..\TargetFrameworkDependentValues.props" /> <PropertyGroup> <OutputPath>$(UtilityOutputFullPath)</OutputPath> </PropertyGroup> [0]: https://github.com/xamarin/xamarin-android/blob/c537dd28c30f482f365ef756214be35aa1553da2/src/apksigner/apksigner.targets#L3-L13 [1]: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022#import-order
Contributor
Author
|
Commit message: Bump to xamarin/java.interop/main@c942ab68 (#7157)
Fixes: https://github.com/xamarin/java.interop/issues/335
Fixes: https://github.com/xamarin/java.interop/issues/954
Fixes: https://github.com/xamarin/java.interop/issues/976
Fixes: https://github.com/xamarin/java.interop/issues/981
Fixes: https://github.com/xamarin/java.interop/issues/992
Changes: https://github.com/xamarin/java.interop/compare/7716ae53da79068e079b17dd4961d0c821bb2c34...c942ab683c12e88e0527ed584a13b411e005ea57
* xamarin/java.interop@c942ab68: [java-source-utils] Build one `$(TargetFramework)` (#1007)
* xamarin/java.interop@b7caa788: [Byecode] Hide `internal` Kotlin fields marked with `@JvmField` (#1004)
* xamarin/java.interop@22d5687b: [generator] Add `@managedOverride` values `none` and `reabstract`. (#1000)
* xamarin/java.interop@7f1d2d7a: [generator] Fix <remove-attr/> metadata (#999)
* xamarin/java.interop@265ad762: [Java.Interop.Tools.JavaSource] Fix tag parsing errors (#997)
* xamarin/java.interop@99c68a86: [Java.Interop] JniTypeSignature & CultureInfo, empty strings (#1002)
* xamarin/java.interop@920ea648: [Java.Interop] optimize JniTypeManager.AssertSimpleReference() (#1001)
* xamarin/java.interop@4b4fedd3: [generator] Process Javadoc for nested types (#996)
Ever since commit 2197a459, CI builds for the `main` branch have been
incredibly flakey: 918613d0 through 27647d2a all failed to complete
the **Mac** stage -- which *must* pass in order for most unit tests
to run -- then dbadf130 built, then f149c25c failed.
Nine commits in the past week have failed to adequately build.
(PR builds, meanwhile, were largely fine.)
Most of these failures are from `make all-tests`:
_ExtractJavadocsFromJavaSourceJars:
/Users/runner/android-toolchain/jdk-11/bin/java -jar /Users/runner/work/1/s/xamarin-android/bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar @/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp1cf0947e.tmp
JAVASOURCEUTILS : warning : Invalid or corrupt jarfile /Users/runner/work/1/s/xamarin-android/bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.McwGen-Tests/Xamarin.Android.McwGen-Tests.csproj]
…
BINDINGSGENERATOR : warning BG8600: Invalid XML file '/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.McwGen-Tests/obj/Release/javadoc-xamarin-test-sources-F6F5170BF7A8BC71.xml': Could not find file "/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.McwGen-Tests/obj/Release/javadoc-xamarin-test-sources-F6F5170BF7A8BC71.xml". For details, see verbose output. [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.McwGen-Tests/Xamarin.Android.McwGen-Tests.csproj]
System.IO.FileNotFoundException: Could not find file "/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.McwGen-Tests/obj/Release/javadoc-xamarin-test-sources-F6F5170BF7A8BC71.xml"
…
"/Users/runner/work/1/s/xamarin-android/Xamarin.Android-Tests.sln" (default target) (1:2) ->
"/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj" (default target) (12:6) ->
(CoreCompile target) ->
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(78,37): error CS1061: 'DataEventArgs' does not contain a definition for 'FromNode' and no accessible extension method 'FromNode' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(79,40): error CS1061: 'DataEventArgs' does not contain a definition for 'FromChannel' and no accessible extension method 'FromChannel' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(80,40): error CS1061: 'DataEventArgs' does not contain a definition for 'PayloadType' and no accessible extension method 'PayloadType' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(81,28): error CS1061: 'DataEventArgs' does not contain a definition for 'Payload' and no accessible extension method 'Payload' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(82,29): error CS1061: 'DataEventArgs' does not contain a definition for 'Payload' and no accessible extension method 'Payload' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(84,51): error CS1061: 'DataEventArgs' does not contain a definition for 'Payload' and no accessible extension method 'Payload' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/BindingTests.cs(85,10): error CS1061: 'DataEventArgs' does not contain a definition for 'Payload' and no accessible extension method 'Payload' accepting a first argument of type 'DataEventArgs' could be found (are you missing a using directive or an assembly reference?) [/Users/runner/work/1/s/xamarin-android/tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj]
`java-source-utils.jar` is (apparently) corrupt, so
`javadoc-xamarin-test-sources-F6F5170BF7A8BC71.xml` is never created,
which means no parameter name information is present, which means the
generated `DataEventArgs` type doesn't have the appropriate property
names, as the property names come from parameter names, and since we
don't have parameter names we instead have property names like `P0`,
`P1`, `P2`, etc.
Why, then, is `java-source-utils.jar` corrupt? The current guess is
that it is being built *concurrently*; from a
`msbuild-20220706T175333-leeroy-all.binlog` build log file from one
of the offending builds, we see:
17:53:44.526 59:11>Target "_BuildJava: (TargetId:490)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point):
17:53:44.526 59:11>Building target "_BuildJava" completely.
Output file "/Users/runner/work/1/s/xamarin-android/bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/33.0.0/tools/java-source-utils.jar" does not exist.
…
17:54:19.564 59:12>Target "DispatchToInnerBuilds: (TargetId:1637)" in file "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/7.0.100-preview.7.22354.2/Microsoft.Common.CrossTargeting.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (target "Build" depends on it):
Task "MSBuild" (TaskId:1099)
Task Parameter:BuildInParallel=True (TaskId:1099)
Task Parameter:Targets=Build (TaskId:1099)
Task Parameter:
Projects=
java-source-utils.csproj
AdditionalProperties=TargetFramework=net7.0 (TaskId:1099)
Additional Properties for project "java-source-utils.csproj": (TaskId:1099)
TargetFramework=net7.0 (TaskId:1099)
…
17:54:19.592 59:12>Target "_BuildJava: (TargetId:1640)" in file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.targets" from project "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/java-source-utils.csproj" (entry point):
Building target "_BuildJava" completely.
Output file "/Users/runner/work/1/s/xamarin-android/external/Java.Interop/../../bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/java-source-utils.jar" does not exist.
…
17:54:41.034 59:11>Done building target "_BuildJava" in project "java-source-utils.csproj".: (TargetId:490)
What appears to be happening -- and there is lots of conjecture here,
as the build log is enormous and it's difficult to piece everything
together -- is that `java-source-utils.csproj` is built *twice*:
Once via `Xamarin.Android.sln`, and once via `apksigner.csproj`, as
it appears that setting `%(PackageReference.AdditionalProperties)`
triggers a *nested build*; note the `DispatchToInnerBuilds` target
which invokes the `<MSBuild/>` Task with the specified
`AdditionalProperties`.
However, that's not the only potential source of concurrent builds;
`java-source-utils.csproj` used `$(TargetFrameworks)` (plural), which
can *also* result in concurrent builds between the "outer" and "inner"
builds used as part of `$(TargetFrameworks)`.
Fix this problem by bumping to xamarin/java.interop@c942ab68, which
updates `java-source-utils.csproj` to use the singular
`$(TargetFramework)` property -- avoiding "outer" and "inner" build
problems -- and "for good measure" update `apksigner.csproj` to
remove `%(ProjectReference.AdditionalProperties)` on
`java-source-utils.csproj`. This should ensure that
`java-source-utils.csproj` is only built *once*, which in turn should
ensure that `java-source-utils.jar` isn't corrupted, and our CI
builds become more reliable. |
jonathanpeppers
approved these changes
Jul 8, 2022
pjcollins
approved these changes
Jul 8, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ever since commit 2197a45, CI builds for the
mainbranch have beenincredibly flakey: 918613d through 27647d2 all failed to complete
the Mac stage -- which must pass in order for most unit tests
to run -- then dbadf13 built, then f149c25 failed.
9 commits in the past week have failed to adequately build.
(PR builds, meanwhile, were largely fine.)
Most of these failures are from
make all-tests:java-source-utils.jaris (apparently) corrupt, sojavadoc-xamarin-test-sources-F6F5170BF7A8BC71.xmlis never created,which means no parameter name information is present, which means the
generated
DataEventArgstype doesn't have the appropriate propertynames, as the property names come from parameter names, and since we
don't have parameter names we instead have property names like
P0,P1,P2, etc.Why, then, is
java-source-utils.jarcorrupt? The current guess isthat it is being built concurrently; from a
msbuild-20220706T175333-leeroy-all.binlogbuild log file from oneof the offending builds, we see:
What appears to be happening -- and there is lots of conjecture here,
as the build log is enormous and it's difficult to piece everything
together -- is that
java-source-utils.csprojis built twice:Once via
Xamarin.Android.sln, and once viaapksigner.csproj, asit appears that setting
%(PackageReference.AdditionalProperties)triggers a nested build; note the
DispatchToInnerBuildstargetwhich invokes the
<MSBuild/>Task with the specifiedAdditionalProperties.Thus, instead of the single
java-source-utils.csprojbuild whichcommit 2197a45 was attempting to introduce, we had two potentially
concurrent builds.
Attempt to fix this by removing the "offending"
%(ProjectReference.AdditionalProperties).