Open jonpryor opened 3 years ago
Note: in the case of xamarin/xamarin-android#5580, the above <add-node/>
does not work, because generator
doesn't like ..
in the name.
If I manually replace all instances of HttpRequest..serializer
with HttpRequest._serializer
, a HttpRequest._serializer
binding is created. Unfortunately it's not valid, because the register attribute is wrong.
Instead, I can add managedName
into the <add-node/>
text, and then it works!
<class
abstract="false"
managedName="HttpRequest._Serializer"
…
Something I hadn't considered.
Regardless, generator
should do more than "silently fail" when a type name has ..
in it.
I just happened to notice the ..
issue in generator
. Leaving a link here for future me:
@jpobst when is this planned... we are stuck with are release...
I'm not sure this really explains what the issue is, or what the desired fix is. Resolving all Java types and removing types and members that depend on types we cannot resolve is a needed step in the binding process, lest we create broken bindings.
I think we would need to explore:
For example, in this reported case:
Error while processing type '[Class] com.vmware.chameleon.http.HttpRequest..serializer': Type 'kotlinx.serialization.internal.GeneratedSerializer' was not found.
Why is GeneratedSerializer
not found? Why do we still want to bind HttpRequest..serializer
if it requires the missing GeneratedSerializer
?
Context: https://github.com/xamarin/xamarin-android/issues/5580
The current binding workflow with
class-parse
results in threeapi.xml
files:class-parse
output, inapi.xml.class-parse
api.xml
(viagenerator --only-xml-adjuster --xml-adjuster-output=api.xml
)Metadata.xml
toapi.xml
, inapi.xml.fixed
.The problem is (2): it removes types present in (1).
Take for example xamarin/xamarin-android#5580, in which the
HttpRequest..serializer
type is not bound.The problem is that it's removed by (2):
and thus is not present in
api.xml
. Consequently, you can't write Metadata.xml transforms which attempt to reference the type, as the type doesn't exist when Metadata.xml is being processed.The only workaround here is to use
<add-node/>
with Metadata.xml, copying the XML fragment fromapi.xml.class-parse
, a'la