Community
Participate
Working Groups
Build Identifier: I20101028-1441 Reason: all IncludeFileContentProvider implementations have workspace dependency. There is no workspace-independent instance for include-file reading: the getSavedFilesProvider() method provides a class (SavedFilesProvider), that handles both. It checks the Workspace first and use external files afterwards. Even if such mixed include-processing is required (system headers?), a workspace-free (only external) implementation should also be present (for standalone parsing). I suggest a new IncludeFileContentProvider.getExternFilesProvider() method with a proper implementation. Please drop me a notice if i should you provide a patch for this: the splitting of the mentioned SavedFilesProvider is pretty straight forward; the resulting extern-reader can be even used as base for it. Reproducible: Always Steps to Reproduce: check the SavedFilesProvider.getContentForInclusion() for dependencies.
(In reply to comment #0) > ... > I suggest a new IncludeFileContentProvider.getExternFilesProvider() method > with a proper implementation. > Please drop me a notice if i should you provide a patch for this: > the splitting of the mentioned SavedFilesProvider is pretty straight forward; > the resulting extern-reader can be even used as base for it. A patch would be nice, I don't see the need for basing SavedFilesProvider on the new FileContentProvider.
