Community
Participate
Working Groups
JVMTypes are resolved by the ClasspathTypeProviderFactory using the ClassLoader of the non-ui Xtext plugin. This seems to work fine for editors and standalone JUnit tests. However it fails for plugin JUnit tests that need to resolve a JVMType defined in the test plugin. This can be worked around by a derived ClasspathTypeProviderFactory that uses the ResourceSet's class loader as the class loader. This could usefully be the standard functionality. The workaround runs into problems with restricted access to ClasspathTypeProviderFactory . Perhaps this could be relaxed.
this can no longer be reproduced since the factory does the following now public ClassLoader getClassLoader(ResourceSet resourceSet) { if (resourceSet instanceof XtextResourceSet) { XtextResourceSet xtextResourceSet = (XtextResourceSet) resourceSet; Object ctx = xtextResourceSet.getClasspathURIContext(); if (ctx != null) { if (ctx instanceof Class<?>) { return ((Class<?>)ctx).getClassLoader(); } if (!(ctx instanceof ClassLoader)) { return ctx.getClass().getClassLoader(); } return (ClassLoader) ctx; } } return classLoader; }
I think the limitation is still there, since your code snippet doesn't help for an ordinary ResourceSet. However to ensure that JVMTypes are resolved in a worker thread, I had to rewrite anyway, so this problem no longer affects me.
should think about this one more
(In reply to Ed Willink from comment #2) > I think the limitation is still there, since your code snippet doesn't help > for an ordinary ResourceSet. This argument turns the bug into a duplicate of bug#326407 *** This bug has been marked as a duplicate of bug 326407 ***
