Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 526820

Summary: Polish: Warning/error marker for unknown nature referenced by project
Product: [Eclipse Project] Platform Reporter: Dani Megert <daniel_megert>
Component: IDEAssignee: Mickael Istria <mistria>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: lbullen
Version: 4.8   
Target Milestone: 4.8 M4   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/r/111082
https://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=1044120af43f20f81f1153298dd71eb16701f106
Whiteboard:
Bug Depends on: 489540    
Bug Blocks:    

Description Dani Megert CLA 2017-11-03 11:34:24 EDT 
I would put the marker on the '.project' file. That allows to directly go to the line/nature when clicking on the problem. It would also allow to invoke a Quick Fix inside the file.

Also, I would set the default to at least 'Info' if not 'Warning'.
Comment 1 Mickael Istria CLA 2017-11-06 03:36:35 EST 
Thanks for these suggestions Dani.
@Lucas: I plan work on them later (next week probably), but if you're interested in working on it and think it has higher priority than your current tasks, feel free to pick it before me.
Comment 2 Mickael Istria CLA 2017-11-06 13:03:27 EST 
Does anyone know a good existing method in Platform core or resources or in dependencies to find a string in a given IFile (or InputStream)? I would rather avoid to implement a KMP algorithm specifically for this feature and I imagine it's already been useful in the past.
Comment 3 Eclipse Genie CLA 2017-11-06 13:22:43 EST 
New Gerrit change created: https://git.eclipse.org/r/111082
Comment 4 Dani Megert CLA 2017-11-09 10:34:22 EST 
(In reply to Mickael Istria from comment #2)
> Does anyone know a good existing method in Platform core or resources or in
> dependencies to find a string in a given IFile (or InputStream)?

You can get the document for a file via file buffer and then use org.eclipse.jface.text.FindReplaceDocumentAdapter. This also has the advantage that it will work on the current state of the document even if open in an editor and dirty.
Comment 5 Dani Megert CLA 2017-11-09 11:13:25 EST 
Found bug 527071 while testing this.
Comment 6 Mickael Istria CLA 2017-11-09 15:17:53 EST 
(In reply to Dani Megert from comment #4)
> You can get the document for a file via file buffer and then use
> org.eclipse.jface.text.FindReplaceDocumentAdapter. This also has the
> advantage that it will work on the current state of the document even if
> open in an editor and dirty.

org.eclipse.core.resources can't depend on JFace. However, this feature can be very useful even in non-JFace world (for example on e(fx)clipse as well) so it's be best to keep in in the org.eclipse.core.resources plugin.
Moreover, the check actually happens on the project resource (and is rendered as marker on the .project), so it's not really suitable to use a document to render the marker and validation can only happen on save.
That said, the FindReplaceDocumentAdapter is inspiring. I'll try something better that covers the whitespaces as well.
Comment 7 Dani Megert CLA 2017-11-10 06:49:18 EST 
(In reply to Mickael Istria from comment #6)
> (In reply to Dani Megert from comment #4)
> > You can get the document for a file via file buffer and then use
> > org.eclipse.jface.text.FindReplaceDocumentAdapter. This also has the
> > advantage that it will work on the current state of the document even if
> > open in an editor and dirty.
> 
> org.eclipse.core.resources can't depend on JFace.

Well, it could. For historical reasons JFace is in the name but the code is in org.eclipse.text. What can't be used are file buffers because that bundle actually depends on core.resources.
Comment 8 Dani Megert CLA 2017-11-10 07:18:23 EST 
(In reply to Dani Megert from comment #7)
> (In reply to Mickael Istria from comment #6)
> > (In reply to Dani Megert from comment #4)
> > > You can get the document for a file via file buffer and then use
> > > org.eclipse.jface.text.FindReplaceDocumentAdapter. This also has the
> > > advantage that it will work on the current state of the document even if
> > > open in an editor and dirty.
> > 
> > org.eclipse.core.resources can't depend on JFace.
> 
> Well, it could...

But thinking of it, we should not add a dependency on org.eclipse.text in the resource layer.
Comment 9 Mickael Istria CLA 2017-11-10 07:42:00 EST 
Ok, in the last version of the patch, I'm still loading the file in memory (like it was already doing) and used a regexp to match the nature. No dependency was added.
Comment 10 Dani Megert CLA 2017-11-10 09:39:08 EST 
(In reply to Mickael Istria from comment #9)
> Ok, in the last version of the patch, I'm still loading the file in memory
> (like it was already doing) and used a regexp to match the nature. No
> dependency was added.

Works for me.