"Pause" migrating everything to a common template, and pivot to moving the remaining packages from the GPS repository to the AndroidX repository. This should enable us to eliminate the circular dependencies between the two repositories which should help fix the majority of the https://github.com/xamarin/AndroidX/issues/764 issues going forward.
Bring in the GPS and Glide templates as new "templateSet", and merge in all the build infrastructure pieces that the GPS repository had to make it build correctly.
Move the packages in GPS that use the following package-specific templates to this repository and switch them to using the default template:
- brotli
- chromium-cronet
- codehaus-mojo
- datatransport
- flatbuffers
- grpc
- opencensus
- perfmark
- protobuf-lite
- squareup-okhttp
- squareup-okhttp3
- squareup-picasso
- squareup-retrofit
- squareup-retrofit2
- squareup-okio
- squareup-javapoet
- tensorflow-lite
- user-messaging-platform
- zxing
One wrinkle is that AndroidX does not allow a stable package to depend on a prerelease package:
```xml
<!-- Warnings we want to error on: -->
<!-- NU5104: A stable release of a package should not have a prerelease dependency. -->
<WarningsAsErrors>$(WarningsAsErrors);NU5104</WarningsAsErrors>
```
Although we should always abide by this rule, we are bound by Google's packaging decisions and sometimes we have no choice. The `Xamarin.TensorFlow.Lite.Support.Api` and `Xamarin.TensorFlow.Lite.Task.Vision.PlayServices.Library` packages we are moving from GPS have a prerelease dependency. (GPS repository does not enforce this rule.)
In order to keep this rule globally, but allow packages to opt out of it, add the `allowPrereleaseDependencies` artifact-level field to `config.json`:
```json
{
"groupId": "org.tensorflow",
"artifactId": "tensorflow-lite-task-vision-play-services",
"version": "0.4.4",
"nugetVersion": "0.4.4.6",
"nugetId": "Xamarin.TensorFlow.Lite.Task.Vision.PlayServices.Library",
"allowPrereleaseDependencies": true,
"comments": "Depends on Xamarin.Google.Android.ODML.Image which only has a prerelease version.",
...
}
```
Companion PR that removes these packages from GPS: https://github.com/xamarin/GooglePlayServicesComponents/pull/906
Move the packages in GPS that use the following package-specific templates to this repository and switch them to using the default template:
- annotations
- aopalliance
- dagger
- errorprone
- findbugs
- inject-guice
- jakarta
- javax-inject
- ow2-asm
Companion PR that removes them from GPS: https://github.com/xamarin/GooglePlayServicesComponents/pull/905
Remove the following package-specific templates in favor of using the default template:
- accompanist
- antmedia-rtpm-client
- auto-value
- dev-chrisbanes-snapper
- flogger
- napier
- reactive-streams
- rxjava
- tink
Additionally, the `Xamarin.Android.ReactiveX.RxJava` NuGet package was relying on a `<JavaSourceJar>` for some parameter names.
Add the artifact-level `documentationType` field to `config.json` that can be specified if a `<JavaSourceJar>` or `<JavaDocJar>` is needed. The default value is `none`, the values `javasource` and `javadoc` are supported.
Some of the final pieces needed to start removing package-specific templates:
- We use the top level `mavenRepositoryType` to default all packages to Google's Maven, and then use the templates to override this to `MavenCentral`. Without templates we will need to specify this directly on the artifact, so add support for an artifact level `mavenRepositoryType`.
- We have several different "types" of packages that we create today:
- `EmbeddedJar` - Basic use of `<EmbeddedJar>` to include the Java payload in the NuGet package next to the managed bindings `.dll`. (This is equivalent to the preferred `<AndroidLibrary>` in .NET 6+.)
- `Targets` - Uses `<InputJar>` to create the binding `.dll` and `<None>` to add the Java payload manually into the NuGet package and uses a `.targets` file to add it to the Android application.
- `NoBindings` - Uses `<None>` to add the Java payload manually into the NuGet package and uses a `.targets` file to add it to the Android application. Does not create managed bindings.
- `XBD` - Uses `<InputJar>` to create the binding `.dll`. The Java payload is not included in the NuGet package. Instead a `.targets` file is used to download the payload at compile time using `Xamarin.Build.Download`.
The default package type is `targets`, which is what the current default template uses. That is, this is the one that all AndroidX packages currently use.
To specify a different package type, we add a new artifact level `type` attribute. The only currently supported value for this is `androidlibrary` which provides the `EmbeddedJar` package type behavior.
As a proof of concept, migrate `GoogleGson` from the `gson` template to the default template.
### Results
Before:
```json
{
"groupId": "com.google.code.gson",
"artifactId": "gson",
"version": "2.11.0",
"nugetVersion": "2.11.0.1",
"nugetId": "GoogleGson",
"dependencyOnly": false,
"templateSet": "gson"
}
```
After:
```json
{
"groupId": "com.google.code.gson",
"artifactId": "gson",
"version": "2.11.0",
"nugetVersion": "2.11.0.1",
"nugetId": "GoogleGson",
"dependencyOnly": false,
"type": "androidlibrary",
"mavenRepositoryType": "MavenCentral"
}
```
Instead of manually maintaining licensing information for packages, pull the license information from the package's POM file. This information looks like:
```xml
<licenses>
<license>
<name>The Apache Software License, Version 2.0</name>
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
<distribution>repo</distribution>
</license>
</licenses>
```
We need to be able to "understand" this license and properties about it, like its SPDX identifier and whether it is proprietary or not. To do this, we match the license name to a new section in `config.json`:
```json
"licenses": [
{
"name": "The Apache Software License, Version 2.0",
"file": "templates/licenses/apache-2.0.txt",
"spdx": "Apache-2.0",
"proprietary": false
}, ...
]
```
Note there may be multiple entries for the "same" license, as different POM files may give it a slightly different name.
These license entries also point to a local copy of the license text that we can use to build `THIRD-PARTY-NOTICES.txt` when `binderator` runs.
Modify the project template to include the generated `THIRD-PARTY-NOTICES.txt` which contains the correct notices for each package rather than the generic repo `External-Dependency-Info.txt` which was not correct for packages not licensed under Apache-2.0.
Finally, if the package is open source and all its license(s) have valid SPDX identifiers, calculate the compound SPDX expression and apply it to the package with `<PackageLicenseExpression>`. If not, use `<PackageLicenseFile>` instead. (SPDX doesn't allow a "proprietary" identifier.)
Note in some cases we may not be able to automatically pull license information from the POM. In these cases we can override the POM information with a new `overrideLicenses` entry on an artifact in `config.json`:
```json
"overrideLicenses": [
"Apache 2.0|http://www.apache.org/licenses/LICENSE-2.0.txt"
],
```
The format is `{license name}|{license url}`.
There is some interesting content available in a Java `.pom` file that we can add to our package readme files:
- Developer(s)
- License(s)
- Description
- Project URL
Add this information, apply some formatting, and remove some less useful information that clutters the readme. Mockup of the new layout on nuget.org:
Other changes:
- `binderator` changes were required to pull in the new fields. Switch to the in-tree version of `binderator` instead of publishing a new `dotnet tool` version.
- Our existing `readme.md` [doesn't work on nuget.org](https://www.nuget.org/packages/Xamarin.AndroidX.Core#readme-body-tab) because we are missing the `$(PackageReadmeFile)` property. Fix this.
- This `readme.md` is intentionally generic enough to be usable by all of our packages. Remove individual template copies.
Context: https://github.com/xamarin/AndroidX/issues/916
`api-diff` currently fails for `Xamarin.AndroidX.Car.App.App` `1.4.0` which is preventing us from updating it. The nature of this crash is documented in https://github.com/xamarin/AndroidX/issues/916.
We have chosen not to spend the resources at this time to fix this tooling error. Instead, we are going to go ahead and update `Xamarin.AndroidX.Car.App.App` to version `1.4.0` and are going to exclude it from running `api-diff`.
Fixes: https://github.com/xamarin/GooglePlayServicesComponents/issues/880
If you try to consume the package `Xamarin.AndroidX.DataStore.Preferences`, you get the following error:
```
JAVA0000: Error in C:\.tools\.nuget\packages\xamarin.androidx.datastore.core.jvm\1.1.1.2\buildTransitive\net8.0-android34.0\..\..\jar\androidx.datastore.datastore-core-jvm.jar:androidx/datastore/core/Actual_jvmKt.class:
JAVA0000: Type androidx.datastore.core.Actual_jvmKt is defined multiple times:
- C:\.tools\.nuget\packages\xamarin.androidx.datastore.core.jvm\1.1.1.2\buildTransitive\net8.0-android34.0\..\..\jar\androidx.datastore.datastore-core-jvm.jar:androidx/datastore/core/Actual_jvmKt.class,
- obj\Release\net8.0-android\lp\30\jl\classes.jar:androidx/datastore/core/Actual_jvmKt.class
```
This is because through the complex set of dependencies, you end up using these 2 packages:
- `Xamarin.AndroidX.DataStore.Core.Android`
- `Xamarin.AndroidX.DataStore.Core.Jvm`
These packages contain the same Java code, the `Android` one seems to be a superset of the `Jvm` one:
Thus we believe the solution is to redirect the `Jvm` package to the `Android` one. That is, anytime the `Jvm` package is requested we are going to give it the `Android` one instead.
We will accomplish this via:
- Adding `Xamarin.AndroidX.DataStore.Core.Android` as a dependency of `Xamarin.AndroidX.DataStore.Core.Jvm`. This means anytime `Jvm` is requested `Android` will also be added.
- Removing the `Jvm` Java library and its bindings from `Xamarin.AndroidX.DataStore.Core.Jvm` so that it will no longer duplicate the bindings and Java library in `Android`.
With these changes, we no longer see the conflict errors when consuming the `Xamarin.AndroidX.DataStore.Preferences*` packages in the `ExtendedTests` suite.
Additionally, bump all the `androidx.datastore` packages so that this new version will get picked up.
Context: https://github.com/xamarin/AndroidX/pull/863
Fixes: https://github.com/dotnet/android/issues/9049
Fixes: https://github.com/xamarin/AndroidX/issues/909
In version `2.8.*`, Google moved all the types in 2 libraries into 2 new libraries:
- `Xamarin.AndroidX.Lifecycle.Common` to `Xamarin.AndroidX.Lifecycle.Common.Jvm`.
- `Xamarin.AndroidX.Lifecycle.ViewModel` to `Xamarin.AndroidX.Lifecycle.ViewModel.Android`.
While this is a source compatible change for users, it is not a binary compatible change for users that are relying on NuGets or assemblies that have not been recompiled.
These types may continue to work in Debug builds, but the linker and AOT compiler steps run for Release builds are unable to resolve the moved types, causing unfixable errors (other than recompiling all assemblies).
Adding `[TypeForwardedToAttribute]` attributes allows the linker and AOT to succeed without recompiling old assemblies.
Jonathan Pobst
moljac