First, I'm not necessarily opposed to having this in Solaris. 0. Lots of our developers work on multiple platforms. For me at least, I prefer a setup that's as similar as possible on all machines. So Solaris packages are of little interest to me (but I don't work on Solaris).
1. When a new final FindBugs release appears, if it's not added to Solaris promptly, then who will want to use the Solaris version? The update latency must not be longer than a month. 2. To integrate into a build/test process (where the FindBugs API is used programmatically), a maven dependency is useful, and maven dependencies are versioned. Automated build and test systems would benefit from this. For this to work, having FindBugs in a maven repository would be helpful (maven isn't the only system, but it's very popular). Probably the FindBugs team should maintain the maven repository, but this is another interesting issue should there be a default install on Solaris. Lloyd .............................................. Lloyd Chambers lloyd.chambers at sun.com GlassFish team, LSARC member On Oct 21, 2008, at 2:11 PM, Petr Slechta wrote: > Hello Tom, > > Tom Childers wrote: >> Petr, >> >> I have several questions about this project. Since this is an open >> case, I'm changing the cc: to lsarc-ext at sun.com. >> >> I am wondering what requirement we are trying to fill with this >> project. FindBugs is downloadable, gets updated frequently, and is >> not prepackaged on any other platform I know of. The version you >> are shipping is already out of date; the 1.3.6 release became >> available a few days ago. >> >> 1. Why does this inclusion in OpenSolaris improve OpenSolaris? >> Won't the subset of users who want it just download it like other >> tools? Is it worth the 7+MB expansion of the OpenSolaris product? > The generic plan is to make Solaris the best OS for developers. So > if a developer may download package created for Solaris them it is > easier for him/her to install the software. > > Also installing software by just unpacking an archive is not very > useful. You will get different structure in this case. You need to > do extra thing to make it work. > > And another goal may be to create IPS (new packaging system) > repository with usable software for developers. > > Anyway, findbugs were approved by our director to be ported to > Solaris. If you think it should not be ported, just let me know your > objections and I may discuss it one more time... > >> >> 2. How do you propose to keep the product current, given the >> aggressive release of new versions? > As any other Solaris packages do... When it is decided that new > version of findbugs should be incorporated in Solaris distribution, > we will refresh sources and will include latest stable version in > the distribution... > >> >> 3. If we're going to package it anywhere, why not include it in the >> NetBeans plugin? > NetBeans plugin can be downloaded via NetBeans update center. But > findbugs may be used by developers that do not use NetBeans (there > is plan to package Eclipse for OpenSolaris for example). And I also > believe that findbugs provides more functions that NetBeans plugin... > > Petr > >> >> Thanks, >> -tdc >> >> >> On Oct 20, 2008, at 12:39 PM, Brian Utterback wrote: >> >>> I am submitting this fast track on behalf of Petr Slechta. Release >>> binding >>> is Micro/patch, although no back port is planned at this time. >>> Time out is >>> set to 10/27/2008. Answers to the FOSS checklist and a man page >>> is included >>> in the case directory. >>> >>> Template Version: @(#)sac_nextcase %I% %G% SMI >>> This information is Copyright 2008 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> findbugs >>> 1.2. Name of Document Author/Supplier: >>> Author: Petr Slechta >>> 1.3 Date of This Document: >>> 20 October, 2008 >>> 4. Technical Description >>> Proposal: >>> >>> Integrate FindBugs into Solaris. >>> >>> >>> Detail: >>> >>> FindBugs[1] is an Java application which uses static >>> analysis techniques >>> to analyze Java code. FindBugs is very useful tool for any >>> Java developer >>> because it finds bugs and problematic places in Java programs. >>> Thus any developer may use it to improve quality of his/her >>> work. >>> >>> FindBugs has GUI and may be also executed in CLI mode. It >>> stores results >>> in plain text or XML. >>> >>> The most recent version of FindBugs at the time of this >>> writing is 1.3.5. >>> The product was last updated by the community on 2008-09-13. >>> The project >>> and the community are active; the releases are on regular >>> basis. >>> As of July, 2008, FindBugs has been downloaded more than >>> 700,000 times. >>> There is plugin for NetBeans IDE [5] that integrates >>> FindBugs into the IDE. >>> Porting of FindBugs into OpenSolaris may help also with >>> adoption of NetBeans IDE. >>> >>> >>> Exported Interfaces: >>> >>> NAME STABILITY NOTES >>> >>> SUNWfindbugs committed package name >>> >>> /usr/bin/findbugs uncommitted startup script >>> /usr/findbugs uncommitted root directory for >>> FindBugs installations >>> >>> >>> Imported Interfaces: >>> >>> NAME STABILITY NOTES >>> >>> JAVA_HOME committed environment >>> variable (widely used) >>> >>> FindBugs require Java 1.5 or later. >>> >>> >>> References: >>> >>> [1] http://findbugs.sourceforge.net/ >>> [2] Finding Bugs is Easy, a paper that appeared in the December >>> 2004 issue of SIGPLAN Notices. >>> An extended abstract of the paper appeared in the OOPSLA 2004 >>> Companion, as part of the >>> Onward! track of the conference. (see >>> http://findbugs.sourceforge.net/publications.html) >>> [3] A Comparison of Bug Finding Tools for Java, by Nick Rutar, >>> Christian Almazan, and Jeff Foster, >>> compares several bug checkers for Java, including FindBugs. >>> (see http://findbugs.sourceforge.net/publications.html) >>> [4] Chris Grindstaff has written a two-part article about FindBugs >>> (Part 1, Part 2) for >>> IBM developerWorks. (see >>> http://findbugs.sourceforge.net/publications.html) >>> [5] http://www.netbeans.org >>> [6] 6759125: FindBugs 1.3.5 to be included into SFW consolidation >>> >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> SFW >>> 6.5. ARC review type: FastTrack >>> 6.6. ARC Exposure: open >>> >> >
