Home » Language IDEs » Java Development Tools (JDT) » Question on Marker use (APT vs. JavaModel)
| Question on Marker use (APT vs. JavaModel) [message #247533] |
Thu, 06 September 2007 13:17  |
Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
I have some custom annotations I've created, and in my
AnnotationProcessor I may flag errors on the annotations using
EclipseMessager.printFixableError(...).
This works fine in the context of the Annotation Processor and Quick fix
processors. However, now i have a need to have these errors be visible
outside of annotation processing (specifically, I want to enable/disable
particular actions based on whether there are annotation errors).
I tried to retrieve the error markers by using
ICompilationUnit.getUnderlyingResource().findMarkers(), but even when
returning all marker types, the markers created by
EclipseMessager.printFixableError() are not being seen.
Question 1: Is there a way to retrieve the markers created by
EclipseMessager.printFixableError starting from an ICompilationUnit?
I tried to work around this by creating a new marker type that extends
the JavaModel problem marker -- but within my annotation processor, if I
try to create a marker of this type on the file, it appears to
re-trigger annotation processing, resulting in infinite recursion.
So if the answer to Question 1 is no, Question 2 is how can I create
problem markers on a file from within an annotation processor without
triggering this recursive behavior?
Thanks,
Mike
|
|
| |
| Re: Question on Marker use (APT vs. JavaModel) [message #247573 is a reply to message #247568] |
Thu, 06 September 2007 19:10  |
| Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
Walter Harley wrote:
> "Mike Yawn" <myawn@ebay.com> wrote in message
> news:fbpcnd$4qj$1@build.eclipse.org...
>> Question 1: Is there a way to retrieve the markers created by
>> EclipseMessager.printFixableError starting from an ICompilationUnit?
>
> Hmm. It must be possible to pull them off the resource in some way; after
> all, the JDT Problems view manages to do so. In my experience the challenge
> is to tell them apart from the other JDT compilation problem markers.
>
> Take a look at AbstractImageBuilder.storeProblemsFor(), and
> IncrementalImageBuilder.updateProblemsFor(), in
> org.eclipse.jdt.internal.core.builder; and at APTProblem.getMarkerType(), in
> org.eclipse.jdt.apt.core.internal.env.
>
>
You're right; I was thinking they must be visible since the problems
view shows them. I think I was trying to see them as I typed; they
don't actually become visible to the Problems view (or in my action code
until I save the file after making the edit that results in the error.
And then, as you indicate, getting at the content to distinguish the
error is an issue.
I looked the at code that creates the markers (EclipseMessager
implementation), and it appears that what I'm creating _ought_ to be an
APTProbem -- which implements IProblem, so I should be able to cast it
to an IProblem, and then use getArguments to retrieve the plugin id &
error id. However, what I'm seeing from .findMarkers is just an
org.eclipse.core.internal.resources.Marker, and if I try to cast it to
an IProblem I get a ClassCastException. The Marker errorids seem to be
random (they are sequential and unrelated to the errorId I passed in at
creation time).
Any ideas of how I can retrieve these markers in a way that allows them
to be cast to IProblems (or some other clever way to get at the content
-- I'm not sure what lurks behind marker.getAttribute for those who have
the attribute name decoder ring)
Mike
|
|
|
| Re: Question on Marker use (APT vs. JavaModel) [message #247578 is a reply to message #247573] |
Thu, 06 September 2007 19:35 |
| Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
Mike Yawn wrote:
> Walter Harley wrote:
>> "Mike Yawn" <myawn@ebay.com> wrote in message
>> news:fbpcnd$4qj$1@build.eclipse.org...
>>> Question 1: Is there a way to retrieve the markers created by
>>> EclipseMessager.printFixableError starting from an ICompilationUnit?
>>
>> Hmm. It must be possible to pull them off the resource in some way;
>> after all, the JDT Problems view manages to do so. In my experience
>> the challenge is to tell them apart from the other JDT compilation
>> problem markers.
>>
>> Take a look at AbstractImageBuilder.storeProblemsFor(), and
>> IncrementalImageBuilder.updateProblemsFor(), in
>> org.eclipse.jdt.internal.core.builder; and at
>> APTProblem.getMarkerType(), in org.eclipse.jdt.apt.core.internal.env.
>>
> You're right; I was thinking they must be visible since the problems
> view shows them. I think I was trying to see them as I typed; they
> don't actually become visible to the Problems view (or in my action code
> until I save the file after making the edit that results in the error.
>
> And then, as you indicate, getting at the content to distinguish the
> error is an issue.
>
> I looked the at code that creates the markers (EclipseMessager
> implementation), and it appears that what I'm creating _ought_ to be an
> APTProbem -- which implements IProblem, so I should be able to cast it
> to an IProblem, and then use getArguments to retrieve the plugin id &
> error id. However, what I'm seeing from .findMarkers is just an
> org.eclipse.core.internal.resources.Marker, and if I try to cast it to
> an IProblem I get a ClassCastException. The Marker errorids seem to be
> random (they are sequential and unrelated to the errorId I passed in at
> creation time).
>
> Any ideas of how I can retrieve these markers in a way that allows them
> to be cast to IProblems (or some other clever way to get at the content
> -- I'm not sure what lurks behind marker.getAttribute for those who have
> the attribute name decoder ring)
>
> Mike
Well, I decided to dump out the contents of the 'getAttributes()' map to
see if that was of any use, and it turns out to have the arguments I was
trying to get from IProblem.
So just to document this for anyone else that might run into the same
question, here's what works for me:
public IMarker[] findJavaProblemMarkers(ICompilationUnit cu) {
try {
IResource javaSourceFile = cu.getUnderlyingResource();
String aptProblemMarker = "org.eclipse.jdt.apt.core.compile.problem";
IMarker[] markers =
//IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER does't see APT
error markers
javaSourceFile.findMarkers(aptProblemMarker,
true, IResource.DEPTH_INFINITE);
for (IMarker marker : markers) {
Map attrs = marker.getAttributes();
String arguments = (String) attrs.get("arguments");
String arg2 = arguments.split("#")[1];
if (arg2.equals(CodegenAnnotationProcessor.DAO_REGEN_NEEDED))
System.err.println("DAO regen required");
else if
(arg2.equals(CodegenAnnotationProcessor.CGDOI_REGEN_NEEDED))
System.err.println("CGDOI regen required");
}
return markers;
} catch (JavaModelException e) {
e.printStackTrace();
} catch (CoreException e) {
e.printStackTrace();
}
return null;
}
|
|
| |
| Re: Question on Marker use (APT vs. JavaModel) [message #248160 is a reply to message #247588] |
Wed, 26 September 2007 18:54 |
| Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
Walter Harley wrote:
> "Mike Yawn" <myawn@ebay.com> wrote in message
> news:46E08EB3.3030008@ebay.com...
>> Well, I decided to dump out the contents of the 'getAttributes()' map to
>> see if that was of any use, and it turns out to have the arguments I was
>> trying to get from IProblem.
>>
>> So just to document this for anyone else [...]
>
> Yes, that seems like the right approach. Problems are a JDT construct built
> upon Markers; APT Problems (or more generally problems contributed by
> CompilationParticipants) are a subset of JDT Problems.
>
> In a perfect world this would probably be available as a public API exposed
> either from JDT as part of the set of interfaces related to
> CompilationParticipant, or from APT as part of the fixableError() interface.
> I think it would be reasonable, if you'd like, to submit such an enhancement
> request.
>
>
Coming back into this after some time -- this is working great for the
case where the user modifies the file and then saves it. But if the
user has unsaved changes that result in problems, there problems are
visible in the editor, but are not seen in either the Problems view or
via the IResource.findMarkers() API.
Is there a trick I can use to make the markers visible, short of saving
the file? I tried ICompilationUnit.reconcile(), but that didn't seem
to do it. The IncrementalImageBuilder.updateProblemsFor() method was
mentioned earlier, but I'm not sure how to obtain a reference to that.
Mike
|
|
|
| Re: Question on Marker use (APT vs. JavaModel) [message #248165 is a reply to message #248160] |
Wed, 26 September 2007 19:47 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Mike Yawn" <myawn@ebay.com> wrote in message
news:46FAE32F.9050108@ebay.com...
> Coming back into this after some time -- this is working great for the
> case where the user modifies the file and then saves it. But if the user
> has unsaved changes that result in problems, there problems are visible in
> the editor, but are not seen in either the Problems view or via the
> IResource.findMarkers() API.
And earlier:
> This works fine in the context of the Annotation Processor and Quick fix
> processors. However, now i have a need to have these errors be visible
> outside of annotation processing (specifically, I want to enable/disable
> particular actions based on whether there are annotation errors).
"Whether there are annotation errors" is ambiguous; there could be an error
in saved code and not in unsaved edited code, or vice versa. If you build
with unsaved changes, the build (and the input to the annotation processor)
reflects what's on disk, not what's in the editor. Which state should your
UI reflect? The saved code, or the latest edits? You might want to
consider other examples - perhaps there's something in the refactoring
menus, which would have similar issues.
When you make edits but don't save a file, the temporary in-memory image is
represented as a "working copy", owned by the editor (in this case the JDT
Text component). Problems reported during compilation (and annotation
processing) of that working copy show up only for the working copy owner,
that is, the editor; or not, depending on the preferences of the working
copy owner. Basically when the owner says "reconcile this", it can pass in
a ProblemRequestor that will be notified of any problems; or it can pass in
null to ignore problems.
So, the behavior of errors in unsaved code appearing in the editor but not
in the problems pane is by design. It's what supports things like letting
you see "what errors would occur" during a refactoring operation.
I'm not sure exactly how you can recover the errors reported to the Java
editor as it reconciles, but I expect that one way or another they need to
come from the working copy owner's problem requestor. Or another approach
is to get the editor's text, create a working copy of your own, and
reconcile that working copy using your own ProblemRequestor. This might run
into issues if there are multiple files with unsaved changes (i.e., would
you get all the changed files, or only the one you grabbed); the answer
might be to act as the default working copy owner (same as the Java editor).
Sorry to be vague about this - I am not very solid in my knowledge of the
Java editor and how it manages working copies.
As a sidebar, editing the declaration of an annotation, or of a base class,
could also in principle cause an annotation processor to report an error.
Also, the Java model seen by the annotation processor if you do a build
while there are unsaved changes can have some inconsistencies, because of
the mix of working copies versus files on disk. These are complex topics
and I don't want to get into the ramifications here, but it's something to
think about.
-Walter Harley
JDT APT team
|
|
|
| Re: Question on Marker use (APT vs. JavaModel) [message #248201 is a reply to message #248165] |
Thu, 27 September 2007 10:17 |
| Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
Thanks so much for taking the time to write up this explanation -- it
really helps me make sense of some of the underlying reasons for why
some things are working the way they do.
I'll do some investigation around the ProblemRequestor -- but at the
same time, I'm going to discuss with other team members whether this is
really the right approach to be taking in this whole area.
Mike
Walter Harley wrote:
> "Mike Yawn" <myawn@ebay.com> wrote in message
> news:46FAE32F.9050108@ebay.com...
>> Coming back into this after some time -- this is working great for the
>> case where the user modifies the file and then saves it. But if the user
>> has unsaved changes that result in problems, there problems are visible in
>> the editor, but are not seen in either the Problems view or via the
>> IResource.findMarkers() API.
>
> And earlier:
>
>> This works fine in the context of the Annotation Processor and Quick fix
>> processors. However, now i have a need to have these errors be visible
>> outside of annotation processing (specifically, I want to enable/disable
>> particular actions based on whether there are annotation errors).
>
>
> "Whether there are annotation errors" is ambiguous; there could be an error
> in saved code and not in unsaved edited code, or vice versa. If you build
> with unsaved changes, the build (and the input to the annotation processor)
> reflects what's on disk, not what's in the editor. Which state should your
> UI reflect? The saved code, or the latest edits? You might want to
> consider other examples - perhaps there's something in the refactoring
> menus, which would have similar issues.
>
> When you make edits but don't save a file, the temporary in-memory image is
> represented as a "working copy", owned by the editor (in this case the JDT
> Text component). Problems reported during compilation (and annotation
> processing) of that working copy show up only for the working copy owner,
> that is, the editor; or not, depending on the preferences of the working
> copy owner. Basically when the owner says "reconcile this", it can pass in
> a ProblemRequestor that will be notified of any problems; or it can pass in
> null to ignore problems.
>
> So, the behavior of errors in unsaved code appearing in the editor but not
> in the problems pane is by design. It's what supports things like letting
> you see "what errors would occur" during a refactoring operation.
>
> I'm not sure exactly how you can recover the errors reported to the Java
> editor as it reconciles, but I expect that one way or another they need to
> come from the working copy owner's problem requestor. Or another approach
> is to get the editor's text, create a working copy of your own, and
> reconcile that working copy using your own ProblemRequestor. This might run
> into issues if there are multiple files with unsaved changes (i.e., would
> you get all the changed files, or only the one you grabbed); the answer
> might be to act as the default working copy owner (same as the Java editor).
> Sorry to be vague about this - I am not very solid in my knowledge of the
> Java editor and how it manages working copies.
>
> As a sidebar, editing the declaration of an annotation, or of a base class,
> could also in principle cause an annotation processor to report an error.
> Also, the Java model seen by the annotation processor if you do a build
> while there are unsaved changes can have some inconsistencies, because of
> the mix of working copies versus files on disk. These are complex topics
> and I don't want to get into the ramifications here, but it's something to
> think about.
>
> -Walter Harley
> JDT APT team
>
>
|
|
|
| Re: Question on Marker use (APT vs. JavaModel) [message #248221 is a reply to message #248201] |
Thu, 27 September 2007 15:20 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Mike Yawn" <myawn@ebay.com> wrote in message
news:46FBBB64.7000100@ebay.com...
>
> I'll do some investigation around the ProblemRequestor -- but at the same
> time, I'm going to discuss with other team members whether this is really
> the right approach to be taking in this whole area.
I think that's always the right attitude around annotation processing...
it's the right solution for a small number of problems, and the wrong
solution for a large number of problems. I don't know enough about your
application to know which class you fall into :-)
|
|
|
Goto Forum:
Current Time: Wed Apr 30 23:25:04 EDT 2025
Powered by FUDForum. Page generated in 0.09145 seconds |
Home