Proposal: NuGet Package(s)?

[jonpryor]

The problem(s):

1. How do we ("reasonably") test generator changes against e.g. xamarin/AndroidX to ensure we don't break things?

2. How do we ("reasonably") update the generator used by e.g. xamarin/AndroidX to fix bugs that are encountered there? (See also #1080)

   Currently the only way to update generator is to update the entire SDK packages used, the Xamarin.Android package and .NET Android package. This is time consuming and cumbersome.

A possible answer? NuGet Packages!

Proposal: begin creating and publishing Java.Interop.* NuGet package(s) which contain generator and related tools.

Open Questions:

• Package name conventions; do we go with Java.Interop as a prefix? Xamarin.Java.Interop or Microsoft.Java.Interop? Other?
• Should generator (and class-parse, and…) be in a global dotnet tool format? Would this need to be a separate pacakge-per-tool, or can multiple such tools be in a single package?
• We have at least one request to publish the "standalone" builds ofJava.Interop.dll and Java.Runtime.Environment.dll in a NuGet package; see also c6c487b62dab4ffec45e61b09dd43afc89898caf. I think this is a reasonable idea. These should not be included in the generator package.

[jpobst]

How do we ("reasonably") test generator changes against e.g. xamarin/AndroidX to ensure we don't break things?

I'm not sure NuGet packages are a good answer here. If we wanted to test a generator PR we would need to create a NuGet package and upload that package "somewhere". Then we would open a PR in AndroidX that references that "somewhere". Unlike the case below, this "somewhere" should not be NuGet.org for an unmerged PR test NuGet.

I think a better plan for this would be a pipeline that runs in Java.Interop using the desired branch that can download the AndroidX repository, build it with a new generator, and run a diff.

This seems easier to set up and easier to run.

How do we ("reasonably") update the generator used by e.g. xamarin/AndroidX to fix bugs that are encountered there?

This is a more interesting proposal, particularly as we may need to get new generator changes into Classic frameworks in AndroidX/GPS.

We may need more clarity around how long we intend to support each framework in AndroidX/GPS:

• Are we really going to remove MonoAndroid12.0 from our packages in May 2024?
• Are we really going to remove net6.0-android from our packages in May 2023?

In both cases I suspect not. I suspect these packages will need to continue shipping the bits our users rely on for a bit longer than the frameworks are technically "supported".

While I don't love the idea of a generator NuGet, we may not have any other choice once we stop shipping Classic/.NET 6 bits. :man_shrugging:

We have at least one request to publish the "standalone" builds of Java.Interop.dll and Java.Runtime.Environment.dll in a NuGet package

Given our available resources, I do not think we should do anything that requires extra work or implies we are supporting additional "niche" cases. Java.Interop is not hard to build and if users are going down an "unsupported" path like this, building JI will probably be the least of their pain. :grin: