Community
Participate
Working Groups
The ClasspathTypeProvider.JavaURIConverter is difficult / impossible to customize. As it's a private inner class, it cannot be extended in user code. Because the (public) ClasspathTypeProvider constructor has a hard-coded cast to this private JavaURIConverter, it's not even possible to copy/paste the private inner class and use that instead. The practical use case why we needed this, if justification is required, is that in-house we have a custom URIConverter, for legacy reasons. That CustomURIConverter holds a reference to something which we need to get hold off. There is some (heavily used) helper util code which, given a Resource, via resource.getResourceSet().getURIConverter() casts to the CustomURIConverter and then getSomething() from it. In that helper, ideally, we would have want to do something like if (uriConverter instanceof ClasspathTypeProvider.JavaURIConverter) and cast then getExisting(). The attached PatchedClasspathTypeProviderFactory extends ClasspathTypeProviderFactory and PatchedClasspathTypeProvider extends ClasspathTypeProvider illustrate futile attempts to customize - not currently possible. The attached ClasspathTypeProviderJavaURIConverterUtil.java illustrates a Reflection-based approach how we were eventually able to get around it - but that's quite ugly of course - ideally this Xtext class should be more extensible. A quick one line change to address this would be to simply make the inner class ClasspathTypeProvider.JavaURIConverter if not entirely public, then at least protected; with that one could probably (not tried) successfully do what I tried in attached, without Reflection. -- Or, and/or make the JavaURIConverter implementation used Guice configurable, so that one can fully customize that, as other APIs.
Created attachment 242201 [details] failed attempt to subclass to customize ClasspathTypeProvider
Created attachment 242202 [details] failed attempt to subclass to customize ClasspathTypeProviderFactory
Created attachment 242204 [details] Reflection-based workaround/hack illustrating how we overcame this issue
Created attachment 242205 [details] Reflection-based workaround/hack illustrating how we overcame this issue