Community
Participate
Working Groups
Build 20020214 While tracing through some code, I noticed that JavaModel.getTarget(...) calls IContainer.findMember(IPath), often with a filesystem path referring to an external jar, e.g. "d:/ibm-sdk-n130p-sr10a/jre/lib/rt.jar". In this case, Core appends the path of the container to the given path (e.g. if container is workspace root: "/ibm-sdk-n130p-sr10a/jre/lib/rt.jar"), and therefore doesn't notice that this is an external path. This would conflict if I actually had a project called "ibm-sdk-n130p-sr10a" and corresponding children. For paths with a device set, findMember should always return null. There might be other Core APIs with the same problem.
Isn't it a bug that the java model is looking in the workspace for an external jar? The device is never interesting for workspace-relative paths, so it is always ignored. The current approach is at least consistent. It would be difficult to consistently fail for paths that contain a device. For example, IContainer#getFile(IPath) cannot return null, so it would have to accept a path with a device in this case.
A classpath entry unfortunately doesn't remember whether it is external or not. The way we get the information is by looking it up first inside the workspace, and if unsuccessfull then we look for a File at the same location.
You can find out if the entry is external by checking for a device on the path. If the path has a device, then it must be external and you don't need to check in the workspace. I'm still flip-flopping on how findMember should behave, I can see arguments for both sides...
Adding Jeem to CC for comments on API behaviour.
A device does not make the resource external - i.e. if I ask a resource for its location, it will contain a device. I should be able to map back to the resource from an absolute path.
Investigate for 2.0. (may require clarification in spec) I'm leaning towards the current behaviour. Current spec says that the given path (be it relative or absolute) is determined to be relative to the receiver. In the case of a path with a device, this would mean dropping the device.
I think you should use IWorkspaceRoot.getFileForLocation(IPath). This method maps from a filesystem path back to the corresponding workspace resource, if any. This is more appropriate, because it expects a file-system path, wherease IContainer.findMember expects a workspace path.
*** Bug 17209 has been marked as a duplicate of this bug. ***
Not planning to fix. Method is arguably behaving as spec'd.
