bintray/jcenter/jfrog removal/replacements #5911
Closed
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
jonathanpeppers
approved these changes
May 5, 2021
Member
jonathanpeppers
left a comment
jonathanpeppers
left a comment
There was a problem hiding this comment.
Tested a couple of these URLs and they seem to work.
This looks good if the build ends up green. 👍
Contributor
Author
|
thanks What about JCenter repo will be read-only forever. Seems that downloads will be possible and even after 2022-02-01 |
Member
|
Honestly, I think it would be fine to wait and only fix URLs that break. Most of these are just unit tests. |
…#5898) Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125 Context: https://github.com/NuGet/NuGet.Client/blob/c529bd75d247430ed19b1713041de0b5b240ef0d/src/NuGet.Core/NuGet.Build.Tasks.Pack/NuGet.Build.Tasks.Pack.targets#L220-L281 The `$(PackageId)` of our workload `.nupkg` needs to be: Microsoft.NET.Sdk.Android.Manifest-6.0.100 While the `$(PackageVersion)` remains the same as before. The layout on disk will change to: dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk.Android\ WorkloadManifest.json WorkloadManifest.targets Note that `.Manifest` and `-6.0.100` are not in the folder name on disk. The generated filename will be e.g. Microsoft.NET.Sdk.Android.Manifest-6.0.100.11.0.200-ci.microsoft-net-sdk-android-manifest.255.nupkg We could find no way to "visually separate" the ".NET version band" of `6.0.100` from the Microsoft.NET.Sdk.Android version of `11.0.200`. Additionally, update `version` in `WorkloadManifest.json` so it contains the proper version for our workload. This used to not be possible because `version` was a `long`, but it now is a `string` where we can put our version.
…5906) Point to Binding Troubleshooting Guide: * https://github.com/xamarin/java.interop/wiki/Troubleshooting-Android-Bindings-Issues Add hints to include `.jar`/`.aar`/diagnostic log.
Contributor
|
For commit message purposes, this could be repurposed: dotnet/java-interop@9444570 |
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4728381&view=ms.vss-test-web.build-test-results-tab&runId=21435278&resultId=100052&paneView=attachments CI on some of our release branches is failing with errors such as: UnnamedProject.csproj: warning MSB4242: The SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" failed to run. An item with the same key has already been added. Key: microsoft-android-sdk-full Microsoft.NET.Sdk.ImportWorkloads.props(14,3): warning MSB4242: The SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" failed to run. An item with the same key has already been added. Key: microsoft-android-sdk-full Microsoft.NET.Sdk.ImportWorkloads.props(14,38): error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. This could happen if both directories exist: dotnet/sdk-manifest/6.0.100/Microsoft.NET.Workload.Android dotnet/sdk-manifest/6.0.100/Microsoft.NET.Sdk.Android Which would define the same Android workload twice. xaprepare was setup to clean certain folders in `$(AndroidToolchainDirectory)\dotnet`, but also needs to delete: * sdk-manifests/6.0.100/*Android* * template-packs/*Android* I also changed some of the string comparisons to use `StringComparison.OrdinalIgnoreCase`.
Context: dotnet/runtime#51274 In .NET 6, `libSystem.Security.Cryptography.Native.OpenSsl.so` needs to be loaded and initialized in order for `System.Security` to be usable. Previously, nothing ensured that the library was loaded, which would result in SIGSEGVs at runtime: [monodroid-assembly] Caching p/invoke entry libSystem.Security.Cryptography.Native.OpenSsl @ AndroidCryptoNative_CipherCreate [monodroid] MonodroidRuntime::monodroid_pinvoke_override ("libSystem.Security.Cryptography.Native.OpenSsl", "AndroidCryptoNative_CipherCreate") [libc] Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5002 (anyname.Android), pid 5002 (anyname.Android) Workaround this problem by updating `MonoPackageManager.java` so that `System.Security.Cryptography.Native.OpenSsl` is always loaded from Java as part of process startup. This is not a desirable solution, as we want to keep *required* process startup overheads as small as possible. Thus, we wish to remove this workaround in the future, once a proper solution is found.
…#5914) Fixes: #5838 Context: e0da1f1 Partially reverts 522d7fb which, reverted d13d0f9. The [`$(AndroidEnablePreloadAssemblies)`][0] property controls whether or not *all* `.dll` files contained within a `.apk` are loaded during process startup. *Not* doing so reduces process startup times, which is desirable, but this also caused certain Xamarin.Forms apps to fail to run as they previously had, as not loading all assemblies during startup broke their Dependency Injection infrastructure. For .NET 6, we feel we have *some* "wiggle-room" to change default semantics, so for .NET 6 projects set the default value of `$(AndroidEnablePreloadAssemblies)` to False, so that assemblies are *not* pre-loaded during process startup. `$(AndroidEnablePreloadAssemblies)` can be set to True within the app's `.csproj` file to return to "legacy" semantics. This will cause all assemblies to be loaded during startup, with a commensurate increase in app startup overheads. [0]: https://docs.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-properties#androidenablepreloadassemblies
Changes: dotnet/installer@eceded1...8e4d77c Changes: dotnet/linker@307f6b0...4afa105 * Update dependencies from https://github.com/dotnet/installer build 20210505.8 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-preview.5.21252.3 -> To Version 6.0.100-preview.5.21255.8 Dependency coherency updates Microsoft.NET.ILLink.Tasks From Version 6.0.100-preview.5.21229.1 -> To Version 6.0.100-preview.5.21254.1 (parent: Microsoft.Dotnet.Sdk.Internal * Update .apkdesc files Co-authored-by: Jonathan Peppers <[email protected]>
Changes: dotnet/java-interop@df4c5e7...4d0cba6 * dotnet/java-interop@4d0cba64: [build] target net6.0 instead of netcoreapp3.1 (#829) * dotnet/java-interop@9444570b: [java-source-utils] Use mavenCentral, not jcenter (#830) * dotnet/java-interop@4ef50813: [Xamarin.Android.Tools.Bytecode] hide Kotlin internal nested types (#827) Other changes are required here to enable Java.Interop to target the `net6.0` target framework.
This feature flag is now on by default in .NET 6.0.100-preview.4.21253.14 and higher. We should stop generating `EnableWorkloadResolver.sentinel`, as it strongly ties our installers to a specific version of the .NET SDK.
Context: https://developer.android.com/about/versions/12/overview Context: https://android-developers.googleblog.com/search/label/Android12 Android 12 [Developer Preview 3 has been released][0]. * [API diff vs. Developer Preview 2][1] * [API diff vs. API-30][2] Google's documented [timeline for Android 12][3] is unchanged vs. commit 11c30ac: * May: Beta 1 * June-July: Beta 2, Beta 3 * August: Beta 4 This contains the final APIs and official SDK. [0]: https://android-developers.googleblog.com/search/label/Android12 [1]: https://developer.android.com/sdk/api_diff/s-dp3-incr/changes [2]: https://developer.android.com/sdk/api_diff/s-dp3/changes [3]: https://developer.android.com/about/versions/12/overview#timeline
Changes: dotnet/java-interop@4d0cba6...12e670a * dotnet/java-interop@12e670a8: [generator] Support binding non-const Java interface fields (#831) * dotnet/java-interop@c925b784: [generator] Support varargs arrays in event listener methods (#832)
grendello
approved these changes
May 11, 2021
pjcollins
requested changes
May 11, 2021
Member
pjcollins
left a comment
pjcollins
left a comment
There was a problem hiding this comment.
Something seems funky with the merge/rebase attempt, I think we need to clean this diff up.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
bintray/jcenter/jfrog removal/replacements
Context: https://blog.gradle.org/jcenter-shutdown
Context: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
JCenter is shutting down. It is no longer browsable as of May 1, and artifacts hosted on JCenter repository will be read-only accessible indefinitely.
Stop using JCenter, and instead use Maven Central.
NOTE: unable to find url replacements:
jbrsdktwitter-coreRelated:
dotnet/java-interop@9444570