Re: Contributing SQE project to NB repository

On 01/18/2012 05:53 PM, Jesse Glick wrote:
> On 01/18/2012 05:44 AM, Jan Lahoda wrote:
>> our ability to make the scans "fast" and "unobtrusive" are certainly
>> going to be
>> limited, compared to our own technologies.
>
> Of course. Will need to be investigated how flexible FB's setup is.
> Ideally we would be able to supply a custom class file provider (so that
> existing *.sig could be loaded directly, rather than copied to *.class
> first, which is quite wasteful); and we would be able to monitor
> detailed progress of the various detectors and cleanly interrupt the
> scan within a few msec of noticing that some higher-priority task is

Right - will need to be investigated.

> coming in. I think we could get patches into FB core if we needed them.
>
>> I would prefer if there would be one "Static Analysis Result"
>> window, into which various tools could provide warnings.
>
> The question is whether the existing Task List window should be used for
> this purpose, or whether we want a separate window with a specialized
> UI. The obvious tradeoffs: a separate window could show richer
> information (such as the bug explanation in SQE's FindBugsTopComponent);
> the Task List window can show a consolidated view with other kinds of
> warnings (making better use of screen space) and has an integrated
> navigation system.

My personal inclination so far was to use a separate window. In fact, we 
already have similar features (Analyze Javadoc, Inspect&Refactor), each 
bringing its own UI. I would prefer to have a window possibly similar to 
Analyze javadoc, which would allow to sort/group the reports based on 
various criteria, show them in a tree structure, show the descriptions, 
maybe even apply fixes of the problems. It would be awesome if we could 
(eventually) get rid of the Analyze Javadoc as a standalone feature. I 
am right now experimenting with a variant of the Analyze Javadoc window 
to show results of the analysis.

>
>> There are quite a few tools that analyze the code, including
>> domain-specific ones
>
> Do you have some examples of other tools (that would be in 7.2) which
> would perform some kind of analysis that would naturally fit in the same
> window? Something in EE perhaps? Creating a generic infrastructure (UI,
> API) for displaying analysis results makes sense if there are several
> known tools which would be offered in the standard 7.2 distribution, so
> we have a good feel for what the possible variations are. If it is just
> FB in 7.2, it seems premature to create an abstraction for this.

Aside from java.hints, I am not aware about anything that would be in 
the std. distro. But there apparently are other analysis tools, and 
allowing reasonable integration of them sounds like a good idea to me. 
But, as I said, I don't want to make promises.

>
> One consideration is that FB (a) operates on class files, not sources,
> (b) can perform cross-class analysis (though a resulting warning
> generally points to a single source line). This contrasts with
> Checkstyle and PMD which scan individual source files; and with existing
> Java editor hints which scan a source file after it has been parsed and
> decorated with semantic information.

Yes, but this applies to showing the warnings in the editor. I do not 
think there is a strong need to introduce a new API for this. Also, the 
FindBugs integration would likely need this to be written separately 
anyway, unless we will have more tools that require classfiles for 
analysis. Other tools may also have their own specifics, and the 
standard APIs are not that complex, IMO and should be flexible enough.

>
> The UI needs to consider what the user does to request, acknowledge, and
> handle warnings. There are four styles of workflow I know of:
>
> 1. Editor hints of all kinds, which are refreshed automatically as you
> type (or in the case of SQE FB, when you save, since it needs class
> files). May be shown in Task List as well as editor. If the hint is a
> false positive, there is a "fix" offered of adding @SuppressWarnings, or
> of just disabling the detector. (Obviously there may be true fixes
> offered as well; FB itself does not help at all here.)
>
> 2. The classic FB standalone UI, and SQE's FindBugsTopComponent, where
> you explicitly run the tool e.g. with a button click, and it shows all
> results typically per project. Less sensitive to performance issues, but
> less convenient to run, and fails to alert you to mistakes as you code.
> No good way to deal with false positives.
>
> 3. The FB 2.0 bug classifier UI, which is like #2 but offers ways of
> categorizing warnings and sharing them with other developers so you do
> not repeatedly see false positives.
>
> 4. Analysis run on a server like Hudson, and results displayed as in #2.
> Good for getting an overview of the health of a project as a whole, and
> pointing out regressions. Has the big drawback that you cannot easily
> check whether a code change clears up a warning.

The static analysis could, at user's discretion, also be run before 
commit, complaining if the code got "worse".

Jan

>
> Sven Reimers wrote:
>> this was one of the goals of SQE - to
>> make integration easier by providing hooks and infrastructure into the
>> complicated hints and java editor infrastructure.
>
> That makes sense as a goal for an external project prioritizing ease of
> integration of lots of tools, but it is not necessarily the right goal
> for a feature maintained as a standard product feature where tight UI
> integration and performance are the priorities and implementors can be
> expected to use the full power of the standard hint APIs.
>
>> It is probably not good if every plugin writer starts with same
>> problems, e.g. accessing maven config info from NetBeans/Maven API's.
>
> Every new API brings its own problems. In the case you mention, I am
> looking at core.maven and most of it is just serving as a wrapper for
> APIs already defined in the IDE's Maven modules. The only real added
> code is findDependencyArtifacts, which (if cleaned up and tested) might
> be useful in the Maven modules themselves; anyway it is not used by the
> FB integration.