You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
jonpryor opened this issue
Feb 16, 2023
· 1 comment
Labels
generatorIssues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yet
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.
The text was updated successfully, but these errors were encountered:
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
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. 😁
generatorIssues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yet
The problem(s):
How do we ("reasonably") test
generator
changes against e.g. xamarin/AndroidX to ensure we don't break things?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 containgenerator
and related tools.Open Questions:
Java.Interop
as a prefix?Xamarin.Java.Interop
orMicrosoft.Java.Interop
? Other?generator
(andclass-parse
, and…) be in a globaldotnet tool
format? Would this need to be a separate pacakge-per-tool, or can multiple such tools be in a single package?Java.Interop.dll
andJava.Runtime.Environment.dll
in a NuGet package; see also c6c487b. I think this is a reasonable idea. These should not be included in thegenerator
package.The text was updated successfully, but these errors were encountered: