-
Notifications
You must be signed in to change notification settings - Fork 60
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
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 contain generator
and related tools.
Open Questions:
- Package name conventions; do we go with
Java.Interop
as a prefix?Xamarin.Java.Interop
orMicrosoft.Java.Interop
? Other? - Should
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? - We have at least one request to publish the "standalone" builds of
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.
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