Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: NuGet Package(s)? #1084

Open
jonpryor opened this issue Feb 16, 2023 · 1 comment
Open

Proposal: NuGet Package(s)? #1084

jonpryor opened this issue Feb 16, 2023 · 1 comment
Labels
generator Issues binding a Java library (generator, class-parse, etc.) proposal Issue raised for discussion, we do not even know if the change would be desirable yet

Comments

@jonpryor
Copy link
Member

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 [generator] Fix NRE by cloning method when copying from base type to derived type. #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 c6c487b. I think this is a reasonable idea. These should not be included in the generator package.
@jonpryor jonpryor added the enhancement Proposed change to current functionality label Feb 16, 2023
@jpobst jpobst removed their assignment Feb 16, 2023
@jpobst jpobst added proposal Issue raised for discussion, we do not even know if the change would be desirable yet and removed enhancement Proposed change to current functionality labels Feb 16, 2023
@jpobst
Copy link
Contributor

jpobst commented Feb 22, 2023

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. 🤷‍♂️

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. 😁

@jpobst jpobst added the generator Issues binding a Java library (generator, class-parse, etc.) label Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generator Issues binding a Java library (generator, class-parse, etc.) proposal Issue raised for discussion, we do not even know if the change would be desirable yet
Projects
None yet
Development

No branches or pull requests

2 participants