This PR addresses #132 (and #146). When resolving includes, as far as possible the real file location is used as base for resolving the include. Within a running eclipse this should always work. More problematic are unit tests where no platform is running and URIs are synthetic.
LilyPondImportUriResolver no longer tries to resolve to a platform URI (i.e. a file located in the workspace) but rather to the absolute file location of the included file. The LilyPondLanguageSpecificURIEditorOpener tries to find a workspace version for such an absolute location and opens that if present - however with the absolute file URI for the openeed file (so find references works #146), otherwise a read-only version is opened as before.
The advantage of this approach should be that import resolution should be more in line with what LilyPond does, relative and absolute includes should also work on Mac/Linux now.
A naive attempt to ensure all base URIs are absolute failed. Trying to set the absolte file URI (rather than the platform URI of the underlying IFile processed during the Xtext build) in the XtextResourceFactory caused IllegalStateExceptions (URI already registered).
File Refactorings will be broken with this PR (LilyPondImportUri is not usable anymore). Fixing this is part of a different issue; as is using index information for determining files needing recompile.
This PR addresses #132 (and #146). When resolving includes, as far as possible the real file location is used as base for resolving the include. Within a running eclipse this should always work. More problematic are unit tests where no platform is running and URIs are synthetic.
LilyPondImportUriResolver no longer tries to resolve to a platform URI (i.e. a file located in the workspace) but rather to the absolute file location of the included file. The LilyPondLanguageSpecificURIEditorOpener tries to find a workspace version for such an absolute location and opens that if present - however with the absolute file URI for the openeed file (so find references works #146), otherwise a read-only version is opened as before.
The advantage of this approach should be that import resolution should be more in line with what LilyPond does, relative and absolute includes should also work on Mac/Linux now.
A naive attempt to ensure all base URIs are absolute failed. Trying to set the absolte file URI (rather than the platform URI of the underlying IFile processed during the Xtext build) in the XtextResourceFactory caused IllegalStateExceptions (URI already registered).
File Refactorings will be broken with this PR (LilyPondImportUri is not usable anymore). Fixing this is part of a different issue; as is using index information for determining files needing recompile.