<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Copied to WINDUP-91<br>
<br>
<br>
<div class="moz-cite-prefix">On 18.6.2014 01:16, Ondrej Zizka wrote:<br>
</div>
<blockquote cite="mid:53A0CC61.6060505@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Just few notes, inline.<br>
<br>
<div class="moz-cite-prefix">On 16.6.2014 16:07, Ian Tewksbury
wrote:<br>
</div>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div>All,</div>
<div><br>
</div>
<div>Pete asked me to send out some of the ideas I have had
about what the Eclipse plugin would like to see from the
Windup core project as far as API goes.</div>
<div><br>
</div>
<div><strong>ProgressMonitor</strong></div>
<div><br>
</div>
<div>I would suggest basing this off the Eclipse
IProgressMonitor API. I do not think it would make sense to
actually use the Eclipse API because then Windup would be
dependent on Eclipse. But if Windup had a similar interface
I could use it to convert form a Windup ProgressMonitor to
an Eclipse IProgressMonitor and report status back to the
user. For Windup's long running actions this is very
important.</div>
</div>
</blockquote>
By nature, the engine core can't tell what the progress is, other
than number of processed vs. remaining rules.<br>
The rules might provide some metadata about how long they expect
to run.<br>
But they don't know until the previous rules are done.<br>
So I guess this will be a bit of guesstimate - perhaps based on
some simple value based on "typical" duration, given by rules as
metadata.<br>
<br>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div><br>
</div>
<div><strong>WinupdEngine</strong></div>
<div><br>
</div>
<div>I think it is important a single instance of the Windup
Engine is reusable and can be run multiple times on the same
project or on different projects. But if for whatever reason
it is only one time use only that needs to be well
documented in the API. Currently with legacy windup I only
create one copy of the Engine</div>
<div><br>
</div>
<div>WindupEngine#setSettings(WindupEnvironment env) - set the
windup options</div>
<div><br>
</div>
<div>WindupEngine#process(File parentProject, ProgressMonitor
monitor) - runs windup on a parent folder and generates all
the metadata</div>
</div>
</blockquote>
Looks like a subset of input. So this would fill one app dir to
input and run, up to, excluding, the report phase.<br>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div>WindupEngine#generateReport(File parentProject,
ProgressMonitor monitor) - generates a windup report based
on all the metadata that is created by the #process(File
parentFolder). This could either error out if the
parentFolder has not yet been processed or could
automatically process it</div>
</div>
</blockquote>
This might need change in current runner, to resume from the
REPORTING phase.<br>
<br>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div>WindupEngine#getRuleMatches(File file) - Should return a
list of RuleMatch objects, one for every rule match on a
given file that can then be used to access any needed
information about that rule match determined from all of the
generated metadata</div>
</div>
</blockquote>
That would probably be a matter of a query to the graph, in the
ideal case.<br>
<br>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div><br>
</div>
<div><strong>RuleMatch</strong></div>
<div><strong><br>
</strong></div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>RuleMatch#getTitle() - a short description title of the
match</div>
<div><br>
</div>
<div>RuleMatch#getLongDescription() - a more verbose
description of the match. this could possible contain some
level of markup/simple html for basic formatting</div>
<div><br>
</div>
<div>RuleMatch#getAdditionalReadingLinks() - returns list of
links to externally extensible information relevant to the
match</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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<br>
<br>
</div>
<div>RuleMatch#getSeverity() - I would suggest a three level
system, info, warning, error.</div>
<div><br>
</div>
<div>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</div>
</div>
</blockquote>
This should become part of the graph model. Perhaps not directly
in a FramedVertex. Could need some DTO to be prepared for this
purpose.<br>
<br>
Ondra<br>
<blockquote
cite="mid:1707054167.18916681.1402927659034.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: Arial; font-size: 12pt; color: #000000">
<div><br>
</div>
<div>----------------------</div>
<div><br>
</div>
<div>That is all I can think of for now. I hope this helps
describe the kind of things Eclipse will be looking for in
terms of API.</div>
<div><br>
</div>
<div>Blue Skies,</div>
<div>~Ian</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
windup-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
windup-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></pre>
</blockquote>
<br>
</body>
</html>