RuleMatch
This should be the class that is used to give API users
all the information that was determined about a given
resource. I would suggest most of this information if not
all of it be lazily loaded and not pre populated. I do not
know what your plan is for the storage of the windup model
you will build on a given project. I hope there is some plan
to not just keep it all in memory all the time and there
will be some sort of file backend. An application like
Eclipse is already a memory hog, to have to store the
possibly infinite size of the windup model for all the
projects in the workspace in memory all the time could get
way out of proportion quickly. My suggestion would be this
model would get saved to disk and then classes like the
RuleMatch could query the model which would in turn query
the disk for information. At the very least if the model is
not saved to disk, then at least text and description from
rules should only be loaded from disk when requested. So
when loading a custom rule you have to load the matcher from
disk as you process, but no need to load the description or
other information until someone actually requests it, and
even then that information should not be kept in memory by
windup when requested, it should be returned and forgotten.
I could go on an on on this subject, and it maybe a topic
for another email or discussion at some point, but wanted to
lay down some of my suggestions as it relates to this API.
I would also assume that the report generator for Winup
would be using this same API to generate the report. I see
the Windup Report generator and the Eclipse plugin as
siblings, both using the same API to display the same
information in different ways.
RuleMatch#getTitle() - a short description title of the
match
RuleMatch#getLongDescription() - a more verbose
description of the match. this could possible contain some
level of markup/simple html for basic formatting
RuleMatch#getAdditionalReadingLinks() - returns list of
links to externally extensible information relevant to the
match
RuleMatch#getLocation() - returns a location object that
will contain the line number and character start and end
locations on that line of the match. If the match if for the
entire file there should be some way of describing that as
well.
RuleMatch#getCategory() - I am guessing rules will be
provided in sets, JEE, WebSphere, Wildfly, or something that
groups rules together in logical sets, this would be nice
for reporting
RuleMatch#getSeverity() - I would suggest a three level
system, info, warning, error.
RuleMatch#getFix() - Should return a block of text that
can replace the matched block of text as a quick fix for the
match. If you want to get really fancy these fixes should be
able to match on parts of the match and inject them into the
quick fix block. EX: if replacing one method call with
another and there are parameters being passed the fix should
be able to have some way of referencing those parameters so
it can use them in its fix. This would all have to be done
on the Windup side and likely all programmaticly by giving
the rule writers access to the source they matched on so
they can parse it for use in their fix code