Re: Contributing SQE project to NB repository

Sorry for being late...

On Wed, Jan 18, 2012 at 7:38 PM, Jesse Glick <[email protected]> wrote=
:
> On 01/18/2012 12:50 PM, Jan Lahoda wrote:
>>
>> we already have similar features (Analyze Javadoc, Inspect&Refactor), ea=
ch
>> bringing its own UI.
>
>
> Analyze Javadoc is indeed similar in style. It is not clear to me that th=
is
> functionality is better displayed in its own window, since I have never u=
sed
> this feature and do not know much about it - perhaps because, in its own
> window, it is much less discoverable than editor hints. What is the use c=
ase
> for this window? Just checking the whole tree and clicking Fix Selected
> would be pointless because then your source base would merely be filled w=
ith
> well-formed but empty Javadoc stubs; if you are really cleaning up Javado=
c
> for a whole project you would want to jump to one warning, create a Javad=
oc
> skeleton either manually (e.g. "/**" and ENTER generates it) or by accept=
ing
> an offer a fix, and complete the documentation of that member, before
> continuing to the next.

Although tools may differ, the existing task list as is provides
probably not enough information, so you end up selecting each one and
have a look at the details (provided by the hint). This was the
initial reason to have a separate UI (for each tool). Maybe it depends
on how much information specific to a tool you want to present, if you
are at least aiming for the common basics of such tools it might be
worth it.

>
> Inspect & Refactor feels different since it is usually used as a preview =
of
> an batch action, though you can also use it to aggregate warnings without
> particular fixes. That is, I would tend to use this window more to
> sanity-check a diff before clicking Refactor, and not so much to browse
> warnings.
>
>> there apparently are other analysis tools, and allowing reasonable
>> integration
>> of them sounds like a good idea to me.
>
>
> It is a matter of timing I guess. If there are several tools that get fit=
ted
> into an API/UI for the same release, then we can be fairly confident that
> the API is useful (even if marked under development). If it is just FB in
> 7.2, then an API would probably be premature. FB provides some rather
> idiosyncratic information in its bug results - not just "X.java:123: some
> warning" but call chains, related occurrences, and HTML-formatted help.
>
> The current UI in SQE provides some integration points such as running al=
l
> tools with a single gesture. However it also creates a separate window fo=
r
> each tool, associated only via a TC group with another generic "control
> center" window. This feels pretty heavyweight for an IDE, though UIs of t=
his
> kind are useful in CI server summary pages.

With FindBugs 2.0 offering those features (collaboration, history) it
might be nice to have the warning before you commit (e.g. just update
a local FindBugs DB with the info from the last build of the project -
someting like a post build analysis step).

>
> Checkstyle also has a lot of rules which are closer to "formatting" than
> "hints" in NB's terminology. In fact the maven.checkstyle module in the I=
DE
> distribution already lets you use a CS definition in the POM as the sourc=
e
> of project-specific formatting conventions, so that Alt-Shift-F will more=
 or
> less follow the CS rules.

+1

>
> PMD and CS also differ critically from FB in that they spew out vast numb=
ers
> of warnings on existing code bases (few of which are indicative of likely
> bugs), so it is only reasonable to use them if you do so from the start o=
n a
> new project, or disable most of their rules. This could affect how they a=
re
> presented in the IDE.

+1

>
> SQE also bundles Dependency Finder but this is barely related to analysis
> tools.

Yes. It was more an approach to make dependency management easier to
do, but it never got very far.

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

+1

>
> You mean compared to the baseline version (hg parent, .svn/text-base/,
> etc.)? Tricky because you would need to restore that version from history
> (and in the case of FB, compile it). I think this kind of thing is better
> left to a CI server and Sonar.

-Sven

--=20
Sven Reimers

* Senior System Engineer and Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* NetBeans Governance Board Member: http://netbeans.org/about/os/governance=
.html
* Community Leader=A0 NetBeans: http://community.java.net/netbeans
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Desktop Java:
http://community.java.net/javadesktop
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=3D1860468
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 http://www.linkedin.com/groups?gid=
=3D107402
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 http://www.linkedin.com/groups?gid=
=3D1684717
* Oracle: https://mix.oracle.com/groups/18497