Community
Participate
Working Groups
This has arisen from investigation into AJDT bug 82341 (in particular comment #7 and comment #13) which found that the SourceLocation.getSystemFile().getPath() call returns the physical location of the file, rather than including the file system link. To reproduce, have the following file setup: ...../workspace/bla ...../workspace/foo ---> bla where bla is a directory and foo is a file system link to bla, and you set your workspace to be foo, then the results of SourceLocation.getSystemFile().getPath() for some file in bla contains ..../workspace/bla/ rather than ..../workspace/foo This is a problem for AJDT because when populating the problems view we try to find the resource using a given string (which is the path to the resource) and the project (in org.eclipse.ajdt.internal.ui.ajde.ProjectProperties.findResource(String, IProject)). We call this with the path calculated from the ISourceLocation (in org.eclipse.ajdt.internal.ui.ajde.CompilerTaskListManager.locationToResource(..)). We then ask the given project to find its member with this path. However, the project returns a location of ..../workspace/foo and consequently we cant find it. This leads to incorrect messages in the problems view.
Created attachment 26222 [details] sample workspace to recreate the problem Use this workspace within AJDT and you will see that the problems view doesn't populate correctly - this is the symptoms from AJDT's point of view.
I spent a couple of hours investigating this last night, as a result of which I almost closed this bug "WONTFIX" - but I won't do that quite yet. The compiler canonicalizes filenames very early on, and then works with canonical filenames througout. I built a "user file name translation map" that mapped a canonical file back to the file name that was originally supplied to the compiler, and a "translating message handler" that would look at source locations for messages and restore source file names to the variant provided by the user. It works, but the results are unpleasant in many situations (you end up with locations like "examples/../examples/x/y/z.java"). Especially when using .lst files which contain file references relative to their own location, it can be just a mess. I've pretty much concluded that working with canonicalized file names throughout is indeed the right thing to do for the command-line compiler. So.... what prevents AJDT from following the same scheme that I was using, only AJDT has extra knowledge that the compiler can't have that makes it much easier. I'm imagining an algorithm like the following: * try to find the resource as normal today * if that fails, compute (if you haven't already) a map from project directory to canonical file name (just get a File for the project dir, and call getCanonicalFile ). Now see if the source location in the message starts with any of these canonical prefixes, and if it does, you have your match * if that fails, it could be sym-links within the project structure itself. Drive "find resource/type" using just the unqualified file name - that will give zero or more matches (hopefully 1 or more). Get the file for each and canonicalize it, the one that matches is your resource... unless there is a compelling reason that AJDT can't do this, I'm going to close out this request against the compiler.
Hi Adrian, Yes, that sounds reasonable. If it makes no sense from a compiler's point of view, then it's up to AJDT to do the right thing. Thanks for the suggested algorithm, I'll start implementing that in AJDT. Please feel free to close this bug against the compiler. Thanks, Helen
closing bug as per discussion in this thread. if it proves impossible to do the right thing in AJDT then we can reopen and take another look...
