-
Notifications
You must be signed in to change notification settings - Fork 64
Open
Labels
generatorIssues binding a Java library (generator, class-parse, etc.)Issues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yetIssue raised for discussion, we do not even know if the change would be desirable yet
Description
The problem(s):
-
How do we ("reasonably") test
generatorchanges against e.g. xamarin/AndroidX to ensure we don't break things? -
How do we ("reasonably") update the
generatorused 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
generatoris 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.Interopas a prefix?Xamarin.Java.InteroporMicrosoft.Java.Interop? Other? - Should
generator(andclass-parse, and…) be in a globaldotnet toolformat? 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 of
Java.Interop.dllandJava.Runtime.Environment.dllin a NuGet package; see also c6c487b. I think this is a reasonable idea. These should not be included in thegeneratorpackage.
AmrAlSayed0
Metadata
Metadata
Assignees
Labels
generatorIssues binding a Java library (generator, class-parse, etc.)Issues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yetIssue raised for discussion, we do not even know if the change would be desirable yet