Community
Participate
Working Groups
I would like to extend org.eclipse.cdt.core.ProblemMarkerInfo to add some more information about markers. There is currently no way to add these markers to org.eclipse.cdt.core.ErrorParserManager. I am attaching a patch which provides that functionality. Thanks.
Created attachment 199710 [details] adds the needed method
Please, provide more details why you need a new method. JavaDoc for ProblemMarkerInfo states that the class is not intended to be subclassed. What kind of information do you want to pass and where?
When a build fails due to a missing dependency we (Autotools plugin) would like to provide the user with the option of installing the missing dependency. To do so I created AutotoolsProblemMarkerInfo extends ProblemMarkerInfo and added a type parameter to it. The type parameter specifies whether this problem is a missing dependency or otherwise, and what kind of dependency it is (header file, library, executable, etc)
(In reply to comment #3) > When a build fails due to a missing dependency we (Autotools plugin) would like > to provide the user with the option of installing the missing dependency. > To do so I created AutotoolsProblemMarkerInfo extends ProblemMarkerInfo and > added a type parameter to it. The type parameter specifies whether this problem > is a missing dependency or otherwise, and what kind of dependency it is (header > file, library, executable, etc) It is not clear to me how the data from ProblemMarkerInfo would get to Autotools plugin. Could you clarify? AFAICS ProblemMarkerInfo ends in ACBuilder where it gets converted to IMarker and any custom data elements get ignored there.
Hmm... That is true so there is no point in extending ProblemMarkerInfo. What would be a way to achieve this then ? I could patch ProblemMarkerInfo to have a misc info field and patch ACBuilder to preserve that if that patch would be acceptable.
(In reply to comment #5) > Hmm... That is true so there is no point in extending ProblemMarkerInfo. > What would be a way to achieve this then ? I could patch ProblemMarkerInfo to > have a misc info field and patch ACBuilder to preserve that if that patch would > be acceptable. I think it might be beneficial to make ProblemMarkerInfo more generic to be able to handle arbitrary IMarker tags. Currently it can deal with just a few hardcoded ones. How about following constructor? public ProblemMarkerInfo(IResource file, int lineNumber, String desciption, int severity, Map<String, String> attributes)
That would be great! Can you do that or would you like me to prepare a patch ?
(In reply to comment #7) > That would be great! Can you do that or would you like me to prepare a patch ? I have no plans to implement that myself but if you submit a patch I'll work with you to get it to CDT.
Created attachment 201263 [details] Add attributes constructor
Created attachment 201264 [details] mylyn/context/zip
Sorry for the delayed reply. A couple of points about the latest attached patch: - I added interface for setting the type because the QuickFix in autotools will be set up to handle only errors of autotools type. - I left addProblemMarker because modifying generateExternalMarker to accept the attributes map made for very awkward looking code when creating the ProblemMarkerInfo object - Related to the previous point I think that it would look better if we remove the attributes map from the constructor and add setAttribute(String, String) and getAttrbiute(String) What do you think ?
There is a lot of unrelated stuff in the patch and it does not apply in eclipse. Could you please clean-up the patch and resubmit? Perhaps you need to rebase against the latest master?
Created attachment 201275 [details] Create more generic API for setting ProblemMarkerInfo My bad. I should have looked at that patch before attaching it. How embarrassing... This is the correct patch. I will attach another one once I have rebased on origin/master just in case.
The changes look pretty reasonable to me, that's pretty much how I would do it given the existing codebase. I only have a few rather formal comments: - You need to add @since tags to new API methods to satisfy API tools. Just add "@since 5.4" in JavaDoc, see ErrorParserManager.getWorkingDirectoryURI() for example. 5.4 is the current version of cdt.core plugin. - Please, add comments to all new public methods you added. ProblemMarkerInfo currently has no JavaDoc at all, could you do an extra and add basic comments to it? - Watch what you copy-paste - "desciption" is misspelled in ProblemMarkerInfo constructor. - We are required to update the second date in copyright header to the current year. See http://wiki.eclipse.org/CDT/policy#Copyright. - I encourage to add your name to the headers of java files. If you do so, it would be good to mention "bug 352166".
... and please do not introduce unused imports warnings :)
Created attachment 201328 [details] Create more generic API for setting ProblemMarkerInfo Thanks for the review :). This is a revised patch. I made the suggested fixes, and added setAttribute and getAttribute API.
Pushed on master, thanks for the patch. I just did a few very cosmetic changes on top, such as in JavaDoc for better readability and fixed the license header. Eclipse Foundation is a bit picky with the format and does not allow 3 years, only 2 - it's a range.
Great! Thanks for the help :)
*** cdt git genie on behalf of Andrew Gvozdev *** bug 352166: Cosmetics [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=67634ea7a882285671f6cee39ff94504a35f3cb8
*** cdt git genie on behalf of Sami Wagiaalla *** bug 352166: ErrorParserManager does not have an API for adding markers [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=e34011c34b7d18a4021219864bcbc5b9fe638deb
*** cdt git genie on behalf of Andrew Gvozdev *** bug 352166: Expressed IMarkerGenerator severity constants via corresponding IMarker ones. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=fe0611ef330dfd6c08aec5a8eeb8566e844ff990
