Community
Participate
Working Groups
We introduced a classpath-uri-scheme in Xtext to refer to EMF-resources. In Xtext's standalone mode, we use a classloader to resolve these URIs, in runtime mode, we rely on the jdt to obtain resources via IJavaProject#getAllPackageFragmentRoots and friends. However, sometimes we face the problem, that an ExternalPackageFragmentRoot returns a resource from ExternalPackageFragmentRoot#resource() that does not return valid members from IFolder#findMember, even if they exist (at least in the filesystem). This problem occures, if we create an IJavaProject with contents in a ui-wizard and try to resolve a classpath-uri, when the java tooling is not yet fully initialized. The workaround, that we came up with, is to fall back to the File-API instead of relying on the Resource-API in these rare cases. The bug seems to be, that ExternalPackageFragmentRoot should not return from resource() when it cannot return an instance, that works as expected. see http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext.ui.core/src/org/eclipse/xtext/ui/core/util/JdtClasspathUriResolver.java?root=Modeling_Project&view=markup for a pointer to the code, that fails during javacore initialization
Please note that the referenced class has been rewritten since Feb 2009.
(In reply to comment #0) > The bug seems to be, that ExternalPackageFragmentRoot should not return from > resource() when it cannot return an instance, that works as expected. Are you saying it should not cache the "this.resource" or that the method should wait until it can find a valid resource? > the filesystem). This problem occures, if we create an IJavaProject with > contents in a ui-wizard and try to resolve a classpath-uri, when the java > tooling is not yet fully initialized. I know it's been a while since you reported this bug, but a test case or a detailed steps will help.
(In reply to comment #2) > I know it's been a while since you reported this bug, but a test case or a > detailed steps will help. As we successfully use a workaround since the early days of Helios, I'm not sure that I can reproduce this issue. This is the code that we use now: // the following code will return null // IResource resource = packageFragmentRoot.getUnderlyingResource(); if (!(packageFragmentRoot instanceof ExternalPackageFragmentRoot)) throw new IllegalStateException(); IResource resource = ((ExternalPackageFragmentRoot)packageFragmentRoot).resource(); Well, I'm not that familiar with the semantics of #getUnderlyingResource() but shouldn't it return the very same instance as the internal #resource() method?
(In reply to comment #3) > Well, I'm not that familiar with the semantics of #getUnderlyingResource() but > shouldn't it return the very same instance as the internal #resource() method? For external elements, such as ExternalPackageFragmentRoot and JarPackageFragmentRoot pointing at an external JAR, the underlying resource is null. Please refer to the documentation - IJavaElement#getResource() and IJavaElement#getUnderlyingResource()
(In reply to comment #4) > Please refer to the documentation - IJavaElement#getResource() and > IJavaElement#getUnderlyingResource() Well from the docs it's still not clear to me why ExternalPackageFragmentRoot#getUnderlyingResource returns null and why "An external package fragment root never has an associated resource." while the internal #resource() returns the information that I need. Is it really necessary to convert the #getPath by myself?
(In reply to comment #5) > Well from the docs it's still not clear to me why > ExternalPackageFragmentRoot#getUnderlyingResource returns null and why "An > external package fragment root never has an associated resource." while the > internal #resource() returns the information that I need. Is it really > necessary to convert the #getPath by myself? In the case of external package fragment root, what the #resource returns is the resource representing the linked folder in the hidden external folder's project. It doesn't really return the underlying resource as such since it's not contained in the workspace. So, I think it makes sense we keep it the way it is now.
Agreed.
Closing this.
Verified.
