From sacadmin Mon Oct 20 12:39:36 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9KJdaqb004986; Mon, 20 Oct 2008 12:39:36 -0700 (PDT) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9KJdarc004982; Mon, 20 Oct 2008 12:39:36 -0700 (PDT) Date: Mon, 20 Oct 2008 12:39:36 -0700 (PDT) From: Brian Utterback Message-Id: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> To: LSARC@sac.sfbay.sun.com Cc: Petr.Slechta@Sun.COM Subject: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Status: RO Content-Length: 3050 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 From sacadmin Mon Oct 20 12:44:49 2008 Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9KJintI005040; Mon, 20 Oct 2008 12:44:49 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9KJk6wD013280; Mon, 20 Oct 2008 12:46:06 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9KJk6HL013279; Mon, 20 Oct 2008 12:46:06 -0700 (PDT) Date: Mon, 20 Oct 2008 12:46:06 -0700 From: Danek Duvall To: Brian Utterback Cc: LSARC@sac.sfbay.sun.com, Petr.Slechta@sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Message-ID: <20081020194606.GZ7489@mumak.SFBay.Sun.COM> References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 265 On Mon, Oct 20, 2008 at 12:39:36PM -0700, Brian Utterback wrote: > /usr/findbugs uncommitted root directory for FindBugs installations Is there a reason you're carving out space under /usr, rather than under /usr/lib or /usr/share? Danek From sacadmin Mon Oct 20 12:59:37 2008 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9KJxagP007676; Mon, 20 Oct 2008 12:59:37 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9KJxXCS036920; Mon, 20 Oct 2008 15:59:34 -0400 (EDT) Message-ID: <48FCE325.7080304@sun.com> Date: Mon, 20 Oct 2008 15:59:33 -0400 From: Brian Utterback User-Agent: Thunderbird 2.0.0.18pre (X11/20081005) MIME-Version: 1.0 To: Danek Duvall CC: Brian Utterback , LSARC@sac.sfbay.sun.com, Petr.Slechta@sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> In-Reply-To: <20081020194606.GZ7489@mumak.SFBay.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1075 Following the BP. We had quite a long discussion on this, but in the end the project team believes that the items under /usr/findbugs are user accessible and not just program accessible. If you have any more questions about what will live there, I will let Petr answer. Danek Duvall wrote: > On Mon, Oct 20, 2008 at 12:39:36PM -0700, Brian Utterback wrote: > >> /usr/findbugs uncommitted root directory for FindBugs installations > > Is there a reason you're carving out space under /usr, rather than under > /usr/lib or /usr/share? > > Danek > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From sacadmin Mon Oct 20 13:09:51 2008 Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9KK9pdT009986; Mon, 20 Oct 2008 13:09:51 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9KKB8Q7013478; Mon, 20 Oct 2008 13:11:08 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9KKB8uX013477; Mon, 20 Oct 2008 13:11:08 -0700 (PDT) Date: Mon, 20 Oct 2008 13:11:08 -0700 From: Danek Duvall To: Brian Utterback Cc: Brian Utterback , LSARC@sac.sfbay.sun.com, Petr.Slechta@sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Message-ID: <20081020201108.GA7489@mumak.SFBay.Sun.COM> References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FCE325.7080304@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 527 On Mon, Oct 20, 2008 at 03:59:33PM -0400, Brian Utterback wrote: > Following the BP. Which Best Practice? > We had quite a long discussion on this, but in the end the project team > believes that the items under /usr/findbugs are user accessible and not > just program accessible. If you have any more questions about what will > live there, I will let Petr answer. By "user accessible", do you mean that pathnames beneath /usr/findbugs are Public interfaces? If so, they need to be in the interface table. Thanks, Danek From sacadmin Tue Oct 21 02:30:17 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9L9UHoA026735; Tue, 21 Oct 2008 02:30:17 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9L9UGvH004434; Tue, 21 Oct 2008 02:30:16 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9L9UAkG007127; Tue, 21 Oct 2008 09:30:11 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300F010T8E100@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM); Tue, 21 Oct 2008 10:30:10 +0100 (BST) Received: from [129.157.21.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9300KCY128YK60@fe-emea-10.sun.com>; Tue, 21 Oct 2008 10:30:08 +0100 (BST) Date: Tue, 21 Oct 2008 11:30:10 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081020201108.GA7489@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@Sun.COM To: Danek Duvall Cc: Brian Utterback , Brian Utterback , LSARC@sac.sfbay.sun.com Message-id: <48FDA122.3090904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 4261 Hello Danek, FindBugs has one main command (that shows GUI, or you can do a lot of things from command line), but has also a lot of other commands that are not so often used. Putting all these commands into /usr/bin would mess up it. Also, I searched how other distributions do package FindBugs. I found the following: /etc/ant.d/findbugs /etc/maven/fragments/findbugs /usr/bin/findbugs /usr/share/applications/jpackage-findbugs.desktop /usr/share/doc/findbugs /usr/share/doc/findbugs/LICENSE.txt /usr/share/doc/findbugs/README.txt /usr/share/doc/findbugs/design /usr/share/doc/findbugs/design/DecouplingFromBCEL.txt /usr/share/doc/findbugs/design/VisitingAndCaching.txt /usr/share/doc/findbugs/design/architecture /usr/share/doc/findbugs/design/architecture/Makefile /usr/share/doc/findbugs/design/architecture/architecture.tex /usr/share/doc/findbugs/design/architecture/attention.pdf /usr/share/doc/findbugs/design/architecture/attention.svg /usr/share/doc/findbugs/design/architecture/mkdep.pl /usr/share/doc/findbugs/design/eclipse findbugs plugin features.sxw /usr/share/findbugs-1.3.4 /usr/share/findbugs-1.3.4/bin /usr/share/findbugs-1.3.4/bin/addMessages /usr/share/findbugs-1.3.4/bin/computeBugHistory /usr/share/findbugs-1.3.4/bin/convertXmlToText /usr/share/findbugs-1.3.4/bin/copyBuggySource /usr/share/findbugs-1.3.4/bin/defectDensity /usr/share/findbugs-1.3.4/bin/deprecated /usr/share/findbugs-1.3.4/bin/deprecated/bugHistory /usr/share/findbugs-1.3.4/bin/deprecated/unionBugs /usr/share/findbugs-1.3.4/bin/deprecated/unionResults /usr/share/findbugs-1.3.4/bin/deprecated/updateBugs /usr/share/findbugs-1.3.4/bin/fbwrap /usr/share/findbugs-1.3.4/bin/filterBugs /usr/share/findbugs-1.3.4/bin/findbugs /usr/share/findbugs-1.3.4/bin/listBugDatabaseInfo /usr/share/findbugs-1.3.4/bin/mineBugHistory /usr/share/findbugs-1.3.4/bin/printAppVersion /usr/share/findbugs-1.3.4/bin/printClass /usr/share/findbugs-1.3.4/bin/rejarForAnalysis /usr/share/findbugs-1.3.4/bin/setBugDatabaseInfo /usr/share/findbugs-1.3.4/bin/unionBugs /usr/share/findbugs-1.3.4/bin/xpathFind /usr/share/icons/hicolor/16x16/apps/findbugs.png /usr/share/icons/hicolor/32x32/apps/findbugs.png /usr/share/icons/hicolor/48x48/apps/findbugs.png /usr/share/java/findbugs /usr/share/java/findbugs/lib /usr/share/java/findbugs/lib/annotations-1.3.4.jar /usr/share/java/findbugs/lib/annotations.jar /usr/share/java/findbugs/lib/asm3-commons.jar /usr/share/java/findbugs/lib/asm3-tree.jar /usr/share/java/findbugs/lib/asm3.jar /usr/share/java/findbugs/lib/bcel5.3.jar /usr/share/java/findbugs/lib/dom4j.jar /usr/share/java/findbugs/lib/findbugs-1.3.4.jar /usr/share/java/findbugs/lib/findbugs-ant-1.3.4.jar /usr/share/java/findbugs/lib/findbugs-ant.jar /usr/share/java/findbugs/lib/findbugs.jar /usr/share/java/findbugs/lib/findbugsGUI-1.3.4.jar /usr/share/java/findbugs/lib/findbugsGUI.jar /usr/share/java/findbugs/lib/jaxen.jar /usr/share/java/findbugs/lib/jcip-annotations.jar /usr/share/java/findbugs/lib/jsr-305.jar /usr/share/java/findbugs/plugin /usr/share/java/findbugs/plugin/coreplugin.jar /usr/share/maven2/poms/JPP.findbugs.lib-annotations.pom /usr/share/maven2/poms/JPP.findbugs.lib-findbugs-ant.pom /usr/share/maven2/poms/JPP.findbugs.lib-findbugs.pom /usr/share/maven2/poms/JPP.findbugs.lib-findbugsGUI.pom /usr/share/maven2/poms/JPP.findbugs.plugin-coreplugin.pom /usr/share/pixmaps/findbugs.png We would like to do the similar thing, put the main command into /usr/bin (/usr/bin/findbugs) and put the other commands into /usr/findbugs/bin. If you have any suggestions how the package structure should look like, I'm open to the discussion... Thanks, Petr Danek Duvall wrote: > On Mon, Oct 20, 2008 at 03:59:33PM -0400, Brian Utterback wrote: > > >> Following the BP. >> > > Which Best Practice? > > >> We had quite a long discussion on this, but in the end the project team >> believes that the items under /usr/findbugs are user accessible and not >> just program accessible. If you have any more questions about what will >> live there, I will let Petr answer. >> > > By "user accessible", do you mean that pathnames beneath /usr/findbugs are > Public interfaces? If so, they need to be in the interface table. > > Thanks, > Danek > From sacadmin Tue Oct 21 06:43:01 2008 Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LDh0er003400 for ; Tue, 21 Oct 2008 06:43:01 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id m9LDh0Cb020821; Tue, 21 Oct 2008 08:43:00 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id m9LDh0WF020820; Tue, 21 Oct 2008 08:43:00 -0500 (CDT) Date: Tue, 21 Oct 2008 08:43:00 -0500 From: Dean Roehrich To: Petr Slechta Cc: Danek Duvall , Brian Utterback , LSARC@sac.sfbay.sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Message-ID: <20081021134300.GA20746@kickball-mn.Central.Sun.COM> References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FDA122.3090904@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 234 On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: > /usr/share/findbugs-1.3.4/bin [...] Will findbugs work if this bin directory is not in the user's PATH? > /usr/share/findbugs-1.3.4/bin/deprecated ...and this? Dean From sacadmin Tue Oct 21 07:01:03 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LE13Bd004097 for ; Tue, 21 Oct 2008 07:01:03 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LE13Hk035967 for ; Tue, 21 Oct 2008 07:01:03 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LE0vYW013758 for ; Tue, 21 Oct 2008 14:00:57 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300E01C8YNG00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC@sac.sfbay.sun.com; Tue, 21 Oct 2008 15:00:57 +0100 (BST) Received: from [129.157.21.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K93002JEDL9GG00@fe-emea-10.sun.com>; Tue, 21 Oct 2008 15:00:45 +0100 (BST) Date: Tue, 21 Oct 2008 16:00:47 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081021134300.GA20746@kickball-mn.Central.Sun.COM> Sender: Petr.Slechta@Sun.COM To: Dean Roehrich Cc: Danek Duvall , Brian Utterback , LSARC@sac.sfbay.sun.com Message-id: <48FDE08F.5000905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> <20081021134300.GA20746@kickball-mn.Central.Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 609 Dean Roehrich wrote: > On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: > >> /usr/share/findbugs-1.3.4/bin >> > [...] > > Will findbugs work if this bin directory is not in the user's PATH? > In /usr/bin there will be link to the main findbugs command, so when the user types "findbugs", the command will be invoked. The other (not so often used) commands will not be accessible without modification of PATH (or without absolute path to the command). Does this answer your question? Petr > > >> /usr/share/findbugs-1.3.4/bin/deprecated >> > > ...and this? > > Dean > From sacadmin Tue Oct 21 08:10:14 2008 Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LFAD6e005735 for ; Tue, 21 Oct 2008 08:10:14 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id m9LFAD2p021215; Tue, 21 Oct 2008 10:10:13 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id m9LFAC5e021214; Tue, 21 Oct 2008 10:10:12 -0500 (CDT) Date: Tue, 21 Oct 2008 10:10:12 -0500 From: Dean Roehrich To: Petr Slechta Cc: Danek Duvall , Brian Utterback , LSARC@sac.sfbay.sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Message-ID: <20081021151012.GA21202@kickball-mn.Central.Sun.COM> References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> <20081021134300.GA20746@kickball-mn.Central.Sun.COM> <48FDE08F.5000905@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FDE08F.5000905@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 887 On Tue, Oct 21, 2008 at 04:00:47PM +0200, Petr Slechta wrote: > Dean Roehrich wrote: > >On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: > > > >>/usr/share/findbugs-1.3.4/bin > >> > >[...] > > > >Will findbugs work if this bin directory is not in the user's PATH? > > > In /usr/bin there will be link to the main findbugs command, so when the > user types "findbugs", the command will be invoked. The other (not so > often used) commands will not be accessible without modification of PATH > (or without absolute path to the command). > > Does this answer your question? Yes, thanks. I was hoping the main findbugs command would know how to find the other commands, without requiring the user to update PATH. > >>/usr/share/findbugs-1.3.4/bin/deprecated > >> > > > >...and this? The user isn't expected to put the 'deprecated' directory in PATH? Dean From sacadmin Tue Oct 21 09:22:32 2008 Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LGMWZI008079; Tue, 21 Oct 2008 09:22:32 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9LGNncH024344; Tue, 21 Oct 2008 09:23:49 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9LGNn39024343; Tue, 21 Oct 2008 09:23:49 -0700 (PDT) Date: Tue, 21 Oct 2008 09:23:49 -0700 From: Danek Duvall To: Petr Slechta Cc: Brian Utterback , Brian Utterback , LSARC@sac.sfbay.sun.com Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Message-ID: <20081021162349.GM7489@mumak.SFBay.Sun.COM> References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FDA122.3090904@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 884 On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: > We would like to do the similar thing, put the main command into /usr/bin > (/usr/bin/findbugs) and put the other commands into /usr/findbugs/bin. > > If you have any suggestions how the package structure should look like, I'm > open to the discussion... /usr/findbugs is probably fine, given all the auxiliary executables. Make sure that the findbugs man page (which doesn't seem to be in that list, so you'll need to write a short one) references /usr/findbugs/bin so that the other programs can be found -- there's little point in shipping a product if it's (almost) completely hidden. Also, it may not be useful to ship any of the maven bits, since we don't appear to ship maven itself. Once we start, you'd need to coordinate paths with that project before any of yours can be confirmed to be useful. Danek From sacadmin Tue Oct 21 09:26:02 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LGQ2oD008117 for ; Tue, 21 Oct 2008 09:26:02 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LGQ1sY005607 for ; Tue, 21 Oct 2008 09:26:01 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LGPtnU003249 for ; Tue, 21 Oct 2008 16:25:55 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300K01K7PZS00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC@sac.sfbay.sun.com; Tue, 21 Oct 2008 17:25:55 +0100 (BST) Received: from [129.157.21.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K93003IWKB7OP50@fe-emea-09.sun.com>; Tue, 21 Oct 2008 17:25:55 +0100 (BST) Date: Tue, 21 Oct 2008 18:25:57 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081021151012.GA21202@kickball-mn.Central.Sun.COM> Sender: Petr.Slechta@Sun.COM To: Dean Roehrich Cc: Danek Duvall , Brian Utterback , LSARC@sac.sfbay.sun.com Message-id: <48FE0295.7040706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> <20081021134300.GA20746@kickball-mn.Central.Sun.COM> <48FDE08F.5000905@sun.com> <20081021151012.GA21202@kickball-mn.Central.Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1539 Dean Roehrich wrote: > On Tue, Oct 21, 2008 at 04:00:47PM +0200, Petr Slechta wrote: > >> Dean Roehrich wrote: >> >>> On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: >>> >>> >>>> /usr/share/findbugs-1.3.4/bin >>>> >>>> >>> [...] >>> >>> Will findbugs work if this bin directory is not in the user's PATH? >>> >>> >> In /usr/bin there will be link to the main findbugs command, so when the >> user types "findbugs", the command will be invoked. The other (not so >> often used) commands will not be accessible without modification of PATH >> (or without absolute path to the command). >> >> Does this answer your question? >> > > Yes, thanks. I was hoping the main findbugs command would know how to find > the other commands, without requiring the user to update PATH. > The other commands are not so often used -- they are used by experts and experts may change their PATH to point to them... (And just to clarify, the main fidbugs command does not need them.) In man page for findbugs, there will be section FILES and the user may easily find the other commands if s/he wants to do it... > > > >>>> /usr/share/findbugs-1.3.4/bin/deprecated >>>> >>>> >>> ...and this? >>> > > The user isn't expected to put the 'deprecated' directory in PATH? > No, these commands are old (deprecated) commands that should not be used (and will be removed in next releases of findbugs). They are there for backward compatibility only... Petr > Dean > From sacadmin Tue Oct 21 09:31:17 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LGVHdl008324; Tue, 21 Oct 2008 09:31:17 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LGVGKA029366; Tue, 21 Oct 2008 09:31:16 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LGVAwB003654; Tue, 21 Oct 2008 16:31:10 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300K01K7PZS00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM); Tue, 21 Oct 2008 17:31:10 +0100 (BST) Received: from [129.157.21.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K930036KKJPOP70@fe-emea-09.sun.com>; Tue, 21 Oct 2008 17:31:02 +0100 (BST) Date: Tue, 21 Oct 2008 18:31:04 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081021162349.GM7489@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@Sun.COM To: Danek Duvall Cc: Brian Utterback , Brian Utterback , LSARC@sac.sfbay.sun.com Message-id: <48FE03C8.1070903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <20081020194606.GZ7489@mumak.SFBay.Sun.COM> <48FCE325.7080304@sun.com> <20081020201108.GA7489@mumak.SFBay.Sun.COM> <48FDA122.3090904@sun.com> <20081021162349.GM7489@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1287 Danek Duvall wrote: > On Tue, Oct 21, 2008 at 11:30:10AM +0200, Petr Slechta wrote: > > >> We would like to do the similar thing, put the main command into /usr/bin >> (/usr/bin/findbugs) and put the other commands into /usr/findbugs/bin. >> >> If you have any suggestions how the package structure should look like, I'm >> open to the discussion... >> > > /usr/findbugs is probably fine, given all the auxiliary executables. Make > sure that the findbugs man page (which doesn't seem to be in that list, so > you'll need to write a short one) references /usr/findbugs/bin so that the > other programs can be found -- there's little point in shipping a product > if it's (almost) completely hidden. > Yes, in manual page, there will be section FILES and there will be written all other commands. So the user will be able to locate them easily. The manual page is already prepared. > Also, it may not be useful to ship any of the maven bits, since we don't > appear to ship maven itself. Once we start, you'd need to coordinate paths > with that project before any of yours can be confirmed to be useful. > Yes, I agree, we will not ship maven files. The listing shows structure of RPM package which we used as inspiration for our own packaging. Petr > Danek > From tom.childers@sun.com Tue Oct 21 10:58:21 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LHwLRX012813 for ; Tue, 21 Oct 2008 10:58:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9LHwLCr021999 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 21 Oct 2008 11:58:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300401OL8Z200@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 10:58:20 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300416OL88F10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 10:58:20 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LHwKbQ021809 for ; Tue, 21 Oct 2008 10:58:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300401NZZRN00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 10:58:20 -0700 (PDT) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.233]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K93003ULOL6RB60@fe-sfbay-10.sun.com>; Tue, 21 Oct 2008 10:58:19 -0700 (PDT) Date: Tue, 21 Oct 2008 10:57:54 -0700 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> Sender: Thomas.Childers@sun.com To: Brian Utterback , Petr.Slechta@sun.com Cc: lsarc-ext@sun.com Message-id: <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> Status: RO Content-Length: 4107 Petr, I have several questions about this project. Since this is an open case, I'm changing the cc: to lsarc-ext@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? 2. How do you propose to keep the product current, given the aggressive release of new versions? 3. If we're going to package it anywhere, why not include it in the NetBeans plugin? 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 > From roehrich@kickball-mn.Central.Sun.COM Tue Oct 21 12:02:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LJ2Nxd016057 for ; Tue, 21 Oct 2008 12:02:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9LJ2K3N049355; Tue, 21 Oct 2008 13:02:20 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300J4FRJV9800@brm-avmta-1.central.sun.com>; Tue, 21 Oct 2008 13:02:19 -0600 (MDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K93008CRRJT65A0@brm-avmta-1.central.sun.com>; Tue, 21 Oct 2008 13:02:17 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LJ2FRb061049; Tue, 21 Oct 2008 13:02:15 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id m9LIsjnY023115; Tue, 21 Oct 2008 13:54:45 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id m9LIsiIf023114; Tue, 21 Oct 2008 13:54:44 -0500 (CDT) Date: Tue, 21 Oct 2008 13:54:44 -0500 From: Dean Roehrich Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> To: Tom Childers Cc: Brian Utterback , Petr.Slechta@sun.com, lsarc-ext@sun.com Message-id: <20081021185444.GA23008@kickball-mn.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 848 On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. If frequency of release of the upstream project is a component of the ARC's decision to accept or reject said project, then those guidelines should be recorded somewhere. We have seen other FOSS cases which admit to porting the version which was current at the time of the OSR but are out of date by the time the ARC cases are submitted. Dean From tom.childers@sun.com Tue Oct 21 12:24:43 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LJOhV2016437 for ; Tue, 21 Oct 2008 12:24:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9LJOgCK057777 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 21 Oct 2008 13:24:43 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300K05SL6S100@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 13:24:42 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K930083ZSL65RC0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 13:24:42 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LJOg8a022445 for ; Tue, 21 Oct 2008 12:24:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300A01S4Q1E00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 12:24:42 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K93005F8SKTYMD0@fe-sfbay-09.sun.com>; Tue, 21 Oct 2008 12:24:38 -0700 (PDT) Date: Tue, 21 Oct 2008 12:24:05 -0700 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081021185444.GA23008@kickball-mn.Central.Sun.COM> Sender: Thomas.Childers@sun.com To: Dean Roehrich Cc: Brian Utterback , Petr.Slechta@sun.com, lsarc-ext@sun.com Message-id: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> Status: RO Content-Length: 1352 On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: > On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. > > If frequency of release of the upstream project is a component of > the ARC's > decision to accept or reject said project, then those guidelines > should be > recorded somewhere. We have seen other FOSS cases which admit to > porting the > version which was current at the time of the OSR but are out of date > by the > time the ARC cases are submitted. Obviously, this is not a part of ARC guidelines. But the question remains, how will the project team keep up the frequent release schedule? And support multiple versions, since there seems to be some dependency between test cases and junit releases? I agree that we have absolutely seen other ARC cases where this becomes a major issue; if we are going to create this dependency, how will we address the issue? -tdc From peter.tribble@gmail.com Tue Oct 21 12:39:44 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LJdi8r016676 for ; Tue, 21 Oct 2008 12:39:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9LJdi3K021415 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 21 Oct 2008 12:39:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300H01TA6CP00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 12:39:42 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300E7RTA611A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 12:39:42 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9LJdfUg019656 for ; Tue, 21 Oct 2008 19:39:41 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-1872617 for lsarc-ext@sun.com; Tue, 21 Oct 2008 19:39:41 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-399777 for lsarc-ext@sun.com; Tue, 21 Oct 2008 19:39:41 +0000 (Z) Received: from ik-out-1112.google.com ([66.249.90.181] [66.249.90.181]) by relay1ib.sun.com with ESMTP id BT-MMP-24971579 for lsarc-ext@sun.com; Tue, 21 Oct 2008 19:39:40 +0000 (Z) Received: by ik-out-1112.google.com with SMTP id c30so1796368ika.0 for ; Tue, 21 Oct 2008 12:39:36 -0700 (PDT) Received: by 10.86.27.9 with SMTP id a9mr81469fga.57.1224617975977; Tue, 21 Oct 2008 12:39:35 -0700 (PDT) Received: by 10.86.97.8 with HTTP; Tue, 21 Oct 2008 12:39:35 -0700 (PDT) Date: Tue, 21 Oct 2008 20:39:35 +0100 From: Peter Tribble Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> To: Tom Childers Cc: Brian Utterback , Petr.Slechta@sun.com, lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gRufeFogFTEPJZVrZjOo6IWSt7fKUdvA2wywbOvQjd8=; b=oBg0xTEaB4jXPN1iN0qKtOyldreODad32ez+D/b3mSozcd0vC0eHH1a0SHSMH1hD0M Qmx1m98BM0U2+7tqFfV1Xru2FZ3MRfb7MxYAJ70lLB8pR/lT/+V1jTWS2Z3wap5+d24p GTL4U52GwO9/26wdsBrZUsjlKPll+WMUEVI5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pkLCGfEgd56QD09SZDcuGt2kdtqJmqKu0gS54i9dvNR2K1KHIYMnvNyTJ74WKRT2m0 dylvDtpI7FgLvkq6F5rZrJDM3fbhmk/uFYXO5hIedLRb1bRIg2pAW09Oh2RiBVPbQeRf 9+/sL+LyLmgWydg7Jhfx9r/XUefggMp2uJRw8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.393sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> Status: RO Content-Length: 1548 On Tue, Oct 21, 2008 at 6:57 PM, 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@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? I'm not so much bothered by the inclusion of findbugs, but would ask whether it is isolated or part of a wider plan to include a full set of similar tools? For example, I use PMD a lot, checkstyle occasionally, and findbugs once in a while. And it seems that the best plan of action is to run several such tools against your code. (Indeed, the reference [3] notes exactly that.) >> Exported Interfaces: >> >> NAME STABILITY NOTES >> >> SUNWfindbugs committed package name >> >> /usr/bin/findbugs uncommitted startup script >> /usr/findbugs uncommitted root directory for Shouldn't that be under /usr/lib or /usr/share, rather than directly under /usr? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From roehrich@kickball-mn.Central.Sun.COM Tue Oct 21 13:57:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LKv9HK020732 for ; Tue, 21 Oct 2008 13:57:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9LKv8ko021707; Tue, 21 Oct 2008 14:57:09 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300K0NWV8WO00@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Oct 2008 13:57:08 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300KKGWV75F20@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Oct 2008 13:57:08 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LKv6Nn008586; Tue, 21 Oct 2008 14:57:06 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id m9LKna1e023815; Tue, 21 Oct 2008 15:49:36 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id m9LKnaJT023814; Tue, 21 Oct 2008 15:49:36 -0500 (CDT) Date: Tue, 21 Oct 2008 15:49:36 -0500 From: Dean Roehrich Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> To: Tom Childers Cc: Brian Utterback , Petr.Slechta@sun.com, lsarc-ext@sun.com Message-id: <20081021204936.GA23679@kickball-mn.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 1914 On Tue, Oct 21, 2008 at 12:24:05PM -0700, Tom Childers wrote: > On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: > >On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. > > > >If frequency of release of the upstream project is a component of > >the ARC's > >decision to accept or reject said project, then those guidelines > >should be > >recorded somewhere. We have seen other FOSS cases which admit to > >porting the > >version which was current at the time of the OSR but are out of date > >by the > >time the ARC cases are submitted. > > Obviously, this is not a part of ARC guidelines. But the question > remains, how will the project team keep up the frequent release > schedule? And support multiple versions, since there seems to be some > dependency between test cases and junit releases? I agree that we have > absolutely seen other ARC cases where this becomes a major issue; if > we are going to create this dependency, how will we address the issue? You're asking if they're going to port every point release, or if, once per time-unit (week, quarter, year, whatever) they'll just pick the latest at that time? Doesn't this apply to every FOSS case? Where does this question belong--ARC, C-Team, Management? It's not clear to me that it belongs at the ARC level. Before we tie findbugs to junit, would someone please confirm whether or not such a dependency exists? It's not clear from the case notes. Dean From Petr.Slechta@sun.com Tue Oct 21 14:11:22 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LLBL72021168 for ; Tue, 21 Oct 2008 14:11:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LLBFou020387 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 21 Oct 2008 22:11:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300L1LXIVGJ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:11:19 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300K91XIT5H50@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:11:18 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LLBGH3015135 for ; Tue, 21 Oct 2008 21:11:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300K01X3TAN00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 22:11:16 +0100 (BST) Received: from [10.162.10.77] ([85.160.24.176]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9300FFWXILSL30@fe-emea-09.sun.com>; Tue, 21 Oct 2008 22:11:15 +0100 (BST) Date: Tue, 21 Oct 2008 23:11:11 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> Sender: Petr.Slechta@sun.com To: Tom Childers Cc: Brian Utterback , lsarc-ext@sun.com Message-id: <48FE456F.7020904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 5420 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@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 >> > From Petr.Slechta@sun.com Tue Oct 21 14:14:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LLEENF021245 for ; Tue, 21 Oct 2008 14:14:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LLE6xL021621 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 21 Oct 2008 22:14:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300L03XNNJY00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:14:11 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300KR9XNM5H50@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:14:10 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LLE9jG015188 for ; Tue, 21 Oct 2008 21:14:09 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300901XIYSE00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 22:14:09 +0100 (BST) Received: from [10.162.10.77] ([85.160.24.176]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9300FA7XMXSL40@fe-emea-09.sun.com>; Tue, 21 Oct 2008 22:13:47 +0100 (BST) Date: Tue, 21 Oct 2008 23:13:47 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> Sender: Petr.Slechta@sun.com To: Tom Childers Cc: Dean Roehrich , Brian Utterback , lsarc-ext@sun.com Message-id: <48FE460B.1040204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1652 Tom Childers wrote: > On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >> >> If frequency of release of the upstream project is a component of the >> ARC's >> decision to accept or reject said project, then those guidelines >> should be >> recorded somewhere. We have seen other FOSS cases which admit to >> porting the >> version which was current at the time of the OSR but are out of date >> by the >> time the ARC cases are submitted. > > Obviously, this is not a part of ARC guidelines. But the question > remains, how will the project team keep up the frequent release > schedule? And support multiple versions, since there seems to be some > dependency between test cases and junit releases? I agree that we have > absolutely seen other ARC cases where this becomes a major issue; if > we are going to create this dependency, how will we address the issue? > -tdc We do not plan to support multiple versions. We may change it if it is a requirement. So is it usual that developer needs to have more versions of findbugs installed? Can you describe the dependency between test cases and junit releases? Thanks! Petr From Petr.Slechta@sun.com Tue Oct 21 14:18:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LLIiQi021362 for ; Tue, 21 Oct 2008 14:18:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9LLId0B019081 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 22 Oct 2008 05:18:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300L01XV5QQ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:18:41 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300KBWXV45F50@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 14:18:40 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LLIdMW026911 for ; Tue, 21 Oct 2008 21:18:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300C01XMXDF00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 21 Oct 2008 22:18:39 +0100 (BST) Received: from [10.162.10.77] ([85.160.24.176]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9300FMTXV1SL50@fe-emea-09.sun.com>; Tue, 21 Oct 2008 22:18:39 +0100 (BST) Date: Tue, 21 Oct 2008 23:18:39 +0200 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: Sender: Petr.Slechta@sun.com To: Peter Tribble Cc: Tom Childers , Brian Utterback , lsarc-ext@sun.com Message-id: <48FE472F.9000707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1858 Peter Tribble wrote: > On Tue, Oct 21, 2008 at 6:57 PM, 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@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? >> > > I'm not so much bothered by the inclusion of findbugs, but would ask whether > it is isolated or part of a wider plan to include a full set of similar tools? > This may be part of the whole goal (to make OpenSolaris the best environment for the developers). However I don't know if someone is working on porting of PMD or checkstyle... I may add your tools to the list of candidates that should be ported to OpenSolaris... What do you think? Petr > For example, I use PMD a lot, checkstyle occasionally, and findbugs once > in a while. And it seems that the best plan of action is to run several such > tools against your code. (Indeed, the reference [3] notes exactly that.) > > >>> Exported Interfaces: >>> >>> NAME STABILITY NOTES >>> >>> SUNWfindbugs committed package name >>> >>> /usr/bin/findbugs uncommitted startup script >>> /usr/findbugs uncommitted root directory for >>> > > Shouldn't that be under /usr/lib or /usr/share, rather than directly under /usr? > > From carlsonj@phorcys.east.sun.com Tue Oct 21 14:26:11 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LLQATO021792 for ; Tue, 21 Oct 2008 14:26:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9LLPmoo021383; Wed, 22 Oct 2008 05:26:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9300403Y7F2G00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 21 Oct 2008 14:26:03 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9300GOMY7E0B80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 21 Oct 2008 14:26:03 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9LLQ1AO008647; Tue, 21 Oct 2008 17:26:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9LLQ1Rb008644; Tue, 21 Oct 2008 17:26:01 -0400 (EDT) Date: Tue, 21 Oct 2008 17:26:01 -0400 From: James Carlson Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081021204936.GA23679@kickball-mn.Central.Sun.COM> To: Dean Roehrich Cc: Tom Childers , Petr.Slechta@sun.com, lsarc-ext@sun.com, Brian Utterback Message-id: <18686.18665.589487.72004@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <20081021204936.GA23679@kickball-mn.Central.Sun.COM> Status: RO Content-Length: 1169 Dean Roehrich writes: > You're asking if they're going to port every point release, or if, once per > time-unit (week, quarter, year, whatever) they'll just pick the latest at that > time? Doesn't this apply to every FOSS case? Where does this question > belong--ARC, C-Team, Management? It's not clear to me that it belongs at the > ARC level. I think it varies in different cases. Sure, we don't want FOSS (or, really, _anything_ -- FOSS isn't that different from other software) to become stale, and semi-frequent updates are desirable. I agree that this is mostly a management issue. There may be an architecture-worthy comment, though, if you say you're chasing some fast-moving design, and if there are notable dependencies on it that require synchronized delivery, or if the delivery mechanism doesn't appear to match that goal. If so, then I think that rates a good "so how will you accomplish this over time?" sort of question. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Jyri.Virkki@sun.com Tue Oct 21 22:28:25 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9M5SPCS002968 for ; Tue, 21 Oct 2008 22:28:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9M5SNUm002298; Tue, 21 Oct 2008 22:28:23 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9400L03KJB3800@brm-avmta-1.central.sun.com>; Tue, 21 Oct 2008 23:28:23 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9400H31KJAJ7B0@brm-avmta-1.central.sun.com>; Tue, 21 Oct 2008 23:28:23 -0600 (MDT) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9M5SLZB023337; Wed, 22 Oct 2008 05:28:22 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id m9M5SLs05618; Tue, 21 Oct 2008 22:28:21 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m9M5SLlK021482; Tue, 21 Oct 2008 22:28:21 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m9M5SLqX021481; Tue, 21 Oct 2008 22:28:21 -0700 (PDT) Date: Tue, 21 Oct 2008 22:28:21 -0700 From: Jyri Virkki Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> To: Tom Childers Cc: Brian Utterback , Petr.Slechta@sun.com, lsarc-ext@sun.com Message-id: <20081022052820.GJ11572@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 2566 Tom Childers wrote: > > I am wondering what requirement we are trying to fill with this > project. FindBugs is downloadable, gets updated frequently, and is not This doesn't seem relevant to the case IMO. Every 3rd party open source component is by definition downloadable and people can just get everything directly from the source. By that view we shouldn't package anything. Which is what we did for a decade while Linux rolled on an Solaris became increasingly unusable in practice. The world moved on and everything is expected to be available in a few seconds with a few keystrokes "apt-get install ....". Now with OpenSolaris and IPS we're finally addressing the problem of package availability. > prepackaged on any other platform I know of. The version you are This one is a useful metric. If an app isn't packaged on most Linux distros, is it really popular enough to bother? But, I find Java apps/libraries to be a special case. Most Linux distros have historically not been very Java friendly. So they tend to not include many Java apps/libraries, not necessarily as a reflection of their popularity in the Java communities but merely because it is in Java. So while the Linux packaging popularity sanity check is a good one to make, it is less useful for Java components. Sun has a certain fondness of Java though, so it makes sense to make OpenSolaris the best platform for Java development & deployment. Making useful Java tools available in IPS helps that goal. FindBugs is a useful tool for Java developers, so +1 on that. > it worth the 7+MB expansion of the OpenSolaris product? Keep in mind all these packages are in IPS, they're optional, only installed by those who want it. > 2. How do you propose to keep the product current, given the > aggressive release of new versions? This is a problem, but not this case. All components have the same issue. As long as Sun insists on the consolidation approach there's going to be a lag and components will be out of date vs. the community. This project team can't solve that. (Not that it is the only reason, and sometimes lagging the community is the smart choice.) The architecturally interesting bit here is the interface stability though. I see findbugs is declared Uncommitted. The exported table is not very specific about what this means exactly? And is it really that stable? (It may be, just asking; remember that Uncommitted despite the name is quite stable, often more so than many open source projects). -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Darren.Moffat@sun.com Wed Oct 22 01:57:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9M8vIxL008339 for ; Wed, 22 Oct 2008 01:57:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9M8vH5s027717 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 22 Oct 2008 01:57:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9400E07U7HDO00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 02:57:17 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K94006BCU7GSRB0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 02:57:16 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9M8vG9G015211 for ; Wed, 22 Oct 2008 08:57:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9400001U629R00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 09:57:15 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9400KIKU7CVR80@fe-emea-10.sun.com>; Wed, 22 Oct 2008 09:57:13 +0100 (BST) Date: Wed, 22 Oct 2008 09:57:11 +0100 From: Darren J Moffat Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <48FE456F.7020904@sun.com> Sender: Darren.Moffat@sun.com To: Petr Slechta Cc: Tom Childers , lsarc-ext@sun.com, Brian Utterback Message-id: <48FEEAE7.2020207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 552 Petr Slechta wrote: > 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... Just because "some director" approved it doesn't mean it actually fits in the architecture of Solaris. As others have asked how does this help Solaris ? I really think this belongs as part of NetBeans more than Solaris. I also really dislike the very generic /usr/bin/findbugs name given what this actually does. -- Darren J Moffat From Joerg.Schilling@fokus.fraunhofer.de Wed Oct 22 02:03:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9M93sP4008520 for ; Wed, 22 Oct 2008 02:03:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9M93pZj000242; Wed, 22 Oct 2008 02:03:51 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9400E0JUIEVQ00@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 03:03:50 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K94006KHUIDST90@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 03:03:49 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9M93llr020802; Wed, 22 Oct 2008 09:03:49 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-919967; Wed, 22 Oct 2008 09:03:47 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-340008; Wed, 22 Oct 2008 09:03:45 +0000 (Z) Received: from iron02.fraunhofer.de ([153.96.1.56] [153.96.1.56]) by relay1i.sun.com with ESMTP id BT-MMP-19683658; Wed, 22 Oct 2008 09:03:45 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Wed, 22 Oct 2008 11:03:44 +0200 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m9M93h7T014756; Wed, 22 Oct 2008 11:03:43 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 11:03:43 +0200 Date: Wed, 22 Oct 2008 11:03:43 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <48FEEAE7.2020207@Sun.COM> To: Petr.Slechta@sun.com, Darren.Moffat@sun.com Cc: tom.childers@sun.com, lsarc-ext@sun.com, blu@sac.sfbay.sun.com Message-id: <48feec6f.mQINpePw8neLdtIB%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.261sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> <48FEEAE7.2020207@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 22 Oct 2008 09:03:43.0876 (UTC) FILETIME=[15AB6C40:01C93425] Status: RO Content-Length: 853 Darren J Moffat wrote: > in the architecture of Solaris. As others have asked how does this help > Solaris ? I really think this belongs as part of NetBeans more than > Solaris. > > I also really dislike the very generic /usr/bin/findbugs name given what > this actually does. How then could it happen that the Imagemagic package could introduce a non-generic program "compare" although a generic "compare" has been published 20+ years before Imagemagic introduced the name "compare"? My impression is that nobody cares :-( Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From brian.utterback@sun.com Wed Oct 22 04:50:34 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MBoY4f010518 for ; Wed, 22 Oct 2008 04:50:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9MBoWFI019332; Wed, 22 Oct 2008 04:50:34 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K950040J289I100@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 05:50:33 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K95003L5289OF00@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 05:50:33 -0600 (MDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9MBoUoe033715; Wed, 22 Oct 2008 07:50:30 -0400 (EDT) Date: Wed, 22 Oct 2008 07:50:29 -0400 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <48FEEAE7.2020207@Sun.COM> To: Darren J Moffat Cc: Petr Slechta , Tom Childers , lsarc-ext@sun.com, Brian Utterback Message-id: <48FF1385.9040503@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> <48FEEAE7.2020207@Sun.COM> User-Agent: Thunderbird 2.0.0.18pre (X11/20081005) Status: RO Content-Length: 1226 Darren J Moffat wrote: > Just because "some director" approved it doesn't mean it actually fits > in the architecture of Solaris. As others have asked how does this help > Solaris ? I really think this belongs as part of NetBeans more than > Solaris. > I think we have already addressed this on this thread. Note that Peter Tribble has already observed that he uses findbugs during application developement, and Petr has already noted that findbugs is useful outside of netbeans, and indeed is limited in its functionality when used with the netbeans plugin. Unlike many of the other FOSS packages on the list waiting for bundling with OpenSolaris, findbugs is used by exactly the OpenSolaris target audience. -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From John.Plocher@sun.com Wed Oct 22 09:03:36 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MG3a2O018839 for ; Wed, 22 Oct 2008 09:03:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9MG3XU1032366 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 22 Oct 2008 10:03:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9500205DXZ0F00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 09:03:35 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9500K22DXZX3A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 09:03:35 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9MG3YqG003755 for ; Wed, 22 Oct 2008 09:03:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9500L01D0ML900@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 22 Oct 2008 09:03:34 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9500KZ1DXKZT90@fe-sfbay-09.sun.com>; Wed, 22 Oct 2008 09:03:20 -0700 (PDT) Date: Wed, 22 Oct 2008 09:03:15 -0700 From: John Plocher Subject: Building a coherent and comprehensive Java development environment on OpenSolaris (was Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008]) In-reply-to: <20081022052820.GJ11572@sun.com> Sender: John.Plocher@sun.com To: Jyri Virkki Cc: Tom Childers , Petr.Slechta@sun.com, lsarc-ext@sun.com, Brian Utterback Message-id: <48FF4EC3.9000207@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081022052820.GJ11572@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 1117 Jyri Virkki wrote: > But, I find Java apps/libraries to be a special case. Most Linux > distros have historically not been very Java friendly. ... > > Sun has a certain fondness of Java though, so it makes sense to make > OpenSolaris the best platform for Java development & deployment. > Making useful Java tools available in IPS helps that goal. I agree with Jyri here (thus the Subject: change), but I'm concerned that we are not in fact building a coherent and comprehensive Java development environment on OpenSolaris as much as we are throwing a random heap of things together with little to no regard for the relationships between them or how they are actually used. In other words, if we *do* end up with OpenSolaris being a good Java development environment, it will be by happy coincidence rather than by intentional design. So, assuming that findbugs is intended to be a part of a larger "Java Friendly" environment, where is the doc that lays out the larger plan for doing this? What other related commands/tools/libs are needed? What relationships exist between them? etc etc etc -John From ceri@submonkey.net Wed Oct 22 12:16:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MJGDhh000176 for ; Wed, 22 Oct 2008 12:16:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9MJFgQn002135; Thu, 23 Oct 2008 03:16:11 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9500D0BMUX0Q00@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 13:16:09 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K95003IEMUW0ND0@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 13:16:08 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9MJG7wO003342; Wed, 22 Oct 2008 19:16:07 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-3635; Wed, 22 Oct 2008 19:16:07 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-29161938; Wed, 22 Oct 2008 19:16:06 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay4i.sun.com with ESMTP id BT-MMP-10651162; Wed, 22 Oct 2008 19:16:06 +0000 (Z) Received: from cpc1-cdif1-0-0-cust63.cdif.cable.ntl.com ([81.104.164.64] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KsjBd-0002mo-97; Wed, 22 Oct 2008 19:16:05 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsjBZ-0006bF-1c; Wed, 22 Oct 2008 20:16:01 +0100 Date: Wed, 22 Oct 2008 20:16:00 +0100 From: Ceri Davies Subject: Re: Building a coherent and comprehensive Java development environment on OpenSolaris (was Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008]) In-reply-to: <48FF4EC3.9000207@Sun.Com> Sender: Ceri Davies To: John Plocher Cc: Jyri Virkki , Tom Childers , Petr.Slechta@sun.com, lsarc-ext@sun.com, Brian Utterback Message-id: <20081022191600.GH39017@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=ZARJHfwaSJQLOEUz Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.534sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081022052820.GJ11572@sun.com> <48FF4EC3.9000207@Sun.Com> User-Agent: Mutt/1.5.18 (2008-05-17) Status: RO Content-Length: 1742 --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 22, 2008 at 09:03:15AM -0700, John Plocher wrote: > Jyri Virkki wrote: > > But, I find Java apps/libraries to be a special case. Most Linux > > distros have historically not been very Java friendly. ... > >=20 > > Sun has a certain fondness of Java though, so it makes sense to make > > OpenSolaris the best platform for Java development & deployment. > > Making useful Java tools available in IPS helps that goal. >=20 > I agree with Jyri here (thus the Subject: change), but I'm concerned=20 > that we are not in fact building a coherent and comprehensive Java=20 > development environment on OpenSolaris as much as we are throwing a=20 > random heap of things together with little to no regard for the=20 > relationships between them or how they are actually used. >=20 > In other words, if we *do* end up with OpenSolaris being a good Java=20 > development environment, it will be by happy coincidence rather than=20 > by intentional design. Agreed. The sentiment expressed at http://is.gd/4zB7 is exactly why I like Solaris but it becoming harder and harder to say with a straight face since the infamous "list of stuff to port without further delay" appeared. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFI/3vwocfcwTS3JF8RAvH2AJ9M1faglj3Z9jUcVOyG2rI71xlniwCeMAqO FTXL4tgLZDYfVKNmKu2LBgQ= =yEe7 -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz-- From Lloyd.Chambers@sun.com Mon Oct 27 11:30:58 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RIUwaU016293 for ; Mon, 27 Oct 2008 11:30:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9RIUtZd027187 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 27 Oct 2008 11:30:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00807U3LPC00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 11:30:57 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E00955U3KZXE0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 11:30:56 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RIUu30012220 for ; Mon, 27 Oct 2008 11:30:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00I01TNJIN00@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 11:30:56 -0700 (PDT) Received: from [192.168.1.8] (diglloyd.com [208.65.183.162]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E002YKU38ZQ60@fe-sfbay-09.sun.com>; Mon, 27 Oct 2008 11:30:46 -0700 (PDT) Date: Mon, 27 Oct 2008 11:30:44 -0700 From: Lloyd Chambers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <48FE460B.1040204@sun.com> Sender: Lloyd.Chambers@sun.com To: Petr Slechta Cc: Tom Childers , Dean Roehrich , Brian Utterback , lsarc-ext@sun.com Message-id: <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> Status: RO Content-Length: 2688 Petr, From my viewpoint as a developer, I'm prepared to download the current version, which I want preferentially because it will have the latest goodies. I'm not all that interested in having a pre-installed versions, because I can just as well keep my own version of choice around. So from my point of view, I just don't see the value. In short, who is the "customer"? Developers probably won't care. In fact, if the version is aggressively moved forward, it may be a nuisance more than anything else (eg paths). Which leads me to another "customer": QA. These folks might want a specific version. So unless we can support more than one version, QA is probably going to keep their own copies around. So who is the customer here? And why would they care? Lloyd .............................................. Lloyd Chambers lloyd.chambers@sun.com GlassFish team, LSARC member On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: > Tom Childers wrote: >> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>> >>> If frequency of release of the upstream project is a component of >>> the ARC's >>> decision to accept or reject said project, then those guidelines >>> should be >>> recorded somewhere. We have seen other FOSS cases which admit to >>> porting the >>> version which was current at the time of the OSR but are out of >>> date by the >>> time the ARC cases are submitted. >> >> Obviously, this is not a part of ARC guidelines. But the question >> remains, how will the project team keep up the frequent release >> schedule? And support multiple versions, since there seems to be >> some dependency between test cases and junit releases? I agree that >> we have absolutely seen other ARC cases where this becomes a major >> issue; if we are going to create this dependency, how will we >> address the issue? >> -tdc > > We do not plan to support multiple versions. We may change it if it > is a requirement. > So is it usual that developer needs to have more versions of > findbugs installed? > Can you describe the dependency between test cases and junit releases? > > Thanks! > > Petr From Lloyd.Chambers@Sun.COM Mon Oct 27 11:50:15 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RIoFFJ016647 for ; Mon, 27 Oct 2008 11:50:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9RIoEKe018625 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 27 Oct 2008 12:50:14 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E0010DUZQMC00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 12:50:14 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E00108UZPM900@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 12:50:13 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RIo9cm025885 for ; Mon, 27 Oct 2008 11:50:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00E01UQG5M00@fe-sfbay-10.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 27 Oct 2008 11:50:09 -0700 (PDT) Received: from [192.168.1.8] (llc4.com [208.65.183.162]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E00C1SUZJ7B80@fe-sfbay-10.sun.com>; Mon, 27 Oct 2008 11:50:08 -0700 (PDT) Date: Mon, 27 Oct 2008 11:50:06 -0700 From: Lloyd Chambers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <48FE456F.7020904@sun.com> Sender: Lloyd.Chambers@Sun.COM To: Petr Slechta Cc: Tom Childers , Brian Utterback , lsarc-ext@Sun.COM Message-id: <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> Status: RO Content-Length: 6768 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@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@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 >>> >> > From brian.utterback@sun.com Mon Oct 27 11:51:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RIp2eT016670 for ; Mon, 27 Oct 2008 11:51:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RIorIK029463; Mon, 27 Oct 2008 18:51:00 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00103V0XN400@brm-avmta-1.central.sun.com>; Mon, 27 Oct 2008 12:50:57 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E0011SV0XLY00@brm-avmta-1.central.sun.com>; Mon, 27 Oct 2008 12:50:57 -0600 (MDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RIordx057057; Mon, 27 Oct 2008 14:50:53 -0400 (EDT) Date: Mon, 27 Oct 2008 14:50:52 -0400 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> To: Lloyd Chambers Cc: Petr Slechta , Tom Childers , Dean Roehrich , Brian Utterback , lsarc-ext@sun.com Message-id: <49060D8C.8090807@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> User-Agent: Thunderbird 2.0.0.18pre (X11/20081005) Status: RO Content-Length: 3544 I disagree. The incremental advantage of using a slightly later version than the one installed is unlikely to persuade developers to download a later one. Looking the changelog for findbugs, the features are evolutionary, not revolutionary from one rev to the next. Lloyd Chambers wrote: > Petr, > > From my viewpoint as a developer, I'm prepared to download the current > version, which I want preferentially because it will have the latest > goodies. I'm not all that interested in having a pre-installed > versions, because I can just as well keep my own version of choice > around. So from my point of view, I just don't see the value. > > In short, who is the "customer"? Developers probably won't care. In > fact, if the version is aggressively moved forward, it may be a nuisance > more than anything else (eg paths). > > Which leads me to another "customer": QA. These folks might want a > specific version. So unless we can support more than one version, QA is > probably going to keep their own copies around. > > So who is the customer here? And why would they care? > > Lloyd > > ............................................. > Lloyd Chambers > lloyd.chambers@sun.com > GlassFish team, LSARC member > > On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: > >> Tom Childers wrote: >>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>> >>>> If frequency of release of the upstream project is a component of >>>> the ARC's >>>> decision to accept or reject said project, then those guidelines >>>> should be >>>> recorded somewhere. We have seen other FOSS cases which admit to >>>> porting the >>>> version which was current at the time of the OSR but are out of date >>>> by the >>>> time the ARC cases are submitted. >>> >>> Obviously, this is not a part of ARC guidelines. But the question >>> remains, how will the project team keep up the frequent release >>> schedule? And support multiple versions, since there seems to be some >>> dependency between test cases and junit releases? I agree that we >>> have absolutely seen other ARC cases where this becomes a major >>> issue; if we are going to create this dependency, how will we address >>> the issue? >>> -tdc >> >> We do not plan to support multiple versions. We may change it if it is >> a requirement. >> So is it usual that developer needs to have more versions of findbugs >> installed? >> Can you describe the dependency between test cases and junit releases? >> >> Thanks! >> >> Petr > > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From roehrich@kickball-mn.Central.Sun.COM Mon Oct 27 13:04:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RK43QK019582 for ; Mon, 27 Oct 2008 13:04:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9RK410d013811; Tue, 28 Oct 2008 04:04:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00601YEOIL00@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Oct 2008 13:04:00 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E005ZEYEOWM00@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Oct 2008 13:04:00 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RK3w5J064954; Mon, 27 Oct 2008 14:03:58 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id m9RJuSLs003799; Mon, 27 Oct 2008 14:56:28 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id m9RJuREQ003798; Mon, 27 Oct 2008 14:56:27 -0500 (CDT) Date: Mon, 27 Oct 2008 14:56:27 -0500 From: Dean Roehrich Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> To: Lloyd Chambers Cc: Petr Slechta , Tom Childers , Brian Utterback , lsarc-ext@sun.com Message-id: <20081027195627.GA3791@kickball-mn.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 417 On Mon, Oct 27, 2008 at 11:50:06AM -0700, Lloyd Chambers wrote: > 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. This applies to all of the FOSS projects we're porting. Every Linux distro also has to deal with this latency. This is not an architecture question. Dean From peter.tribble@gmail.com Mon Oct 27 13:22:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RKMpbD020376 for ; Mon, 27 Oct 2008 13:22:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RKMfXG005799; Mon, 27 Oct 2008 20:22:49 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00807Z9YD100@brm-avmta-1.central.sun.com>; Mon, 27 Oct 2008 14:22:46 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E001P3Z9YM740@brm-avmta-1.central.sun.com>; Mon, 27 Oct 2008 14:22:46 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RKLgX7018791; Mon, 27 Oct 2008 20:22:45 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay22i.sun.com with ESMTP id BT-MMP-23869; Mon, 27 Oct 2008 20:22:45 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-596535; Mon, 27 Oct 2008 20:22:45 +0000 (Z) Received: from mu-out-0910.google.com ([209.85.134.188] [209.85.134.188]) by relay23i.sun.com with ESMTP id BT-MMP-805691; Mon, 27 Oct 2008 20:22:45 +0000 (Z) Received: by mu-out-0910.google.com with SMTP id w8so2327474mue.8 for ; Mon, 27 Oct 2008 13:21:52 -0700 (PDT) Received: by 10.181.150.16 with SMTP id c16mr1936002bko.150.1225138912097; Mon, 27 Oct 2008 13:21:52 -0700 (PDT) Received: by 10.180.235.20 with HTTP; Mon, 27 Oct 2008 13:21:51 -0700 (PDT) Date: Mon, 27 Oct 2008 20:21:51 +0000 From: Peter Tribble Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> To: Lloyd Chambers Cc: Petr Slechta , Tom Childers , lsarc-ext@sun.com, Brian Utterback Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=I3L1ajuehlV2/nG14cq8zq871cucDibUV+JyOUhNE+8=; b=hsnhpj296/6qMBr9JWgYNpQL2A996cWQyNtW/zdsx9cjtJgd5+xwxfdSNwmZ7o5taz /suVhLSYiMvEQGjHbfRwMuXzSeyA1/i857qceuEjjEorQYCix7kIlNVv0ap29u9z4zGw 3prbPBizIbmo6uleZes2NB+7bkDBvevv631x0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jjb6TEjg4B2ZtYo12tlzZ44fRLlVxGR13g/wqbez61cyA4IrosUqsJ+NYi92sdTSUf OabldfI4NEM0xl7hnkH4xYj/wT+FknTf3KYdP5hNo1qbkqRjWXJpgDqFLEjVOEG3MhKw FwwOBLy7BII6VOYE0p12DiRNzcA+iDniB0JCM= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.274sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> Status: RO Content-Length: 1233 > 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). But I would much rather that someone else took responsibilty for supplying and supporting the setup, rather than me having to maintain it myself on all the machines I use. So having tools coming preinstalled is good. That is, if what's preinstalled is complete. See also John Plocher's comment. While I do use findbugs, I don't use it in isolation - and if I've got to hunt down and install half my toolset, then there's relatively little value in just having some of the bits. > 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. I normally have the opposite issue - I often end up maintaining my own copies of tools (and deinstalling the system ones) to stop things from being changed underneath me. But this is a generic packaging and delivery issue, rather than architectural. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Lloyd.Chambers@Sun.COM Tue Oct 28 09:12:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SGCvkF023905 for ; Tue, 28 Oct 2008 09:12:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9SGCvjJ053973 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 28 Oct 2008 10:12:57 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00H05IDJG800@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 09:12:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00GUAIDJ6K10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 09:12:55 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SGCtYQ004329 for ; Tue, 28 Oct 2008 09:12:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9G00H01HSCYW00@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 09:12:55 -0700 (PDT) Received: from [192.168.1.8] (llc4.com [208.65.183.162]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9G007HGIDIHR00@fe-sfbay-09.sun.com>; Tue, 28 Oct 2008 09:12:55 -0700 (PDT) Date: Tue, 28 Oct 2008 09:12:54 -0700 From: Lloyd Chambers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081027195627.GA3791@kickball-mn.Central.Sun.COM> Sender: Lloyd.Chambers@Sun.COM To: Dean Roehrich Cc: Petr Slechta , Tom Childers , Brian Utterback , lsarc-ext@Sun.COM Message-id: <1E748DFE-2310-4780-8AFE-0F3780823C89@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <48FE456F.7020904@sun.com> <0ADC8665-4ED8-4F68-9817-5CB51C2F695F@sun.com> <20081027195627.GA3791@kickball-mn.Central.Sun.COM> Status: RO Content-Length: 940 Yes, it applies to all FOSS projects. But it's very much a question of practical consequence for using FOSS. What is "architectural" exactly? AFAIK maintenance *is* an architectural question because it speaks directly to: - version or version(s) installed - when and how versions are updated - backward/forward compatibility Lloyd .............................................. Lloyd Chambers lloyd.chambers@sun.com GlassFish team, LSARC member On Oct 27, 2008, at 12:56 PM, Dean Roehrich wrote: > On Mon, Oct 27, 2008 at 11:50:06AM -0700, Lloyd Chambers wrote: >> 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. > > This applies to all of the FOSS projects we're porting. Every Linux > distro > also has to deal with this latency. > > This is not an architecture question. > > Dean From tom.childers@sun.com Tue Oct 28 10:31:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SHVUMM000167 for ; Tue, 28 Oct 2008 10:31:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SHVGSe007175 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 29 Oct 2008 01:31:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00L07M0F5O00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 10:31:27 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00J5ZM0EN840@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 10:31:26 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SHVQcF016515 for ; Tue, 28 Oct 2008 10:31:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9G00K01KRALJ00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 10:31:26 -0700 (PDT) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.233]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9G00H3IM03MYF0@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 28 Oct 2008 10:31:16 -0700 (PDT) Date: Tue, 28 Oct 2008 10:31:08 -0700 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49060D8C.8090807@sun.com> Sender: Thomas.Childers@sun.com To: Brian Utterback Cc: Petr Slechta , Dean Roehrich , lsarc-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> Status: RO Content-Length: 4394 Brian, We discussed this case, and the junit case, in our OpenARC meeting this morning. We are extending the timer on this fast-track to Friday: 1. we will be writing an opinion for the junit case, 2008/633, and the content will impact the location of your deliverables. We are talking about putting all java tools into /usr/share/lib/java, but the discussion is not finished. 2. we are curious about the programmatic interface for findbugs, and if that is available in this project. If so, it needs to be an exported interface; if not, other ARC members would like to know why it's not available. I'm sure more email is forthcoming :-) Thanks, -tdc On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: > I disagree. The incremental advantage of using a slightly later > version than the one installed is unlikely to persuade developers to > download a later one. Looking the changelog for findbugs, the > features are evolutionary, not revolutionary from one rev to the next. > > Lloyd Chambers wrote: >> Petr, >> From my viewpoint as a developer, I'm prepared to download the >> current version, which I want preferentially because it will have >> the latest goodies. I'm not all that interested in having a pre- >> installed versions, because I can just as well keep my own version >> of choice around. So from my point of view, I just don't see the >> value. >> In short, who is the "customer"? Developers probably won't care. >> In fact, if the version is aggressively moved forward, it may be a >> nuisance more than anything else (eg paths). >> Which leads me to another "customer": QA. These folks might want a >> specific version. So unless we can support more than one version, >> QA is probably going to keep their own copies around. >> So who is the customer here? And why would they care? >> Lloyd >> ............................................. >> Lloyd Chambers >> lloyd.chambers@sun.com >> GlassFish team, LSARC member >> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>> Tom Childers wrote: >>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>> >>>>> If frequency of release of the upstream project is a component >>>>> of the ARC's >>>>> decision to accept or reject said project, then those guidelines >>>>> should be >>>>> recorded somewhere. We have seen other FOSS cases which admit >>>>> to porting the >>>>> version which was current at the time of the OSR but are out of >>>>> date by the >>>>> time the ARC cases are submitted. >>>> >>>> Obviously, this is not a part of ARC guidelines. But the question >>>> remains, how will the project team keep up the frequent release >>>> schedule? And support multiple versions, since there seems to be >>>> some dependency between test cases and junit releases? I agree >>>> that we have absolutely seen other ARC cases where this becomes a >>>> major issue; if we are going to create this dependency, how will >>>> we address the issue? >>>> -tdc >>> >>> We do not plan to support multiple versions. We may change it if >>> it is a requirement. >>> So is it usual that developer needs to have more versions of >>> findbugs installed? >>> Can you describe the dependency between test cases and junit >>> releases? >>> >>> Thanks! >>> >>> Petr > > -- > blu > > "Murderous organizations have increased in size and scope; they are > more daring, they are served by the most terrible weapons offered by > modern science, and the world is nowadays threatened by new forces > which, if recklessly unchained, may some day wreck universal > destruction." - Arthur Griffith, 1898 > ---------------------------------------------------------------------- > Brian Utterback - Solaris RPE, Sun Microsystems, Inc. > Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From brian.utterback@sun.com Tue Oct 28 11:23:05 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SIN5sV002534 for ; Tue, 28 Oct 2008 11:23:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9SIN32x015294; Tue, 28 Oct 2008 11:23:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00M1FOEFY500@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 11:23:03 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00J76OEEN480@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 11:23:03 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SIN0im061179; Tue, 28 Oct 2008 14:23:01 -0400 (EDT) Date: Tue, 28 Oct 2008 14:23:00 -0400 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: To: Tom Childers Cc: Petr Slechta , Dean Roehrich , lsarc-ext@sun.com Message-id: <49075884.5000505@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> User-Agent: Thunderbird 2.0.0.18pre (X11/20081021) Status: RO Content-Length: 5155 Right. I was on the call. I will work with Petr to resolve the missing API issues, and we eagerly await the opinion as to how and where it should be installed. Tom Childers wrote: > Brian, > > We discussed this case, and the junit case, in our OpenARC meeting this > morning. We are extending the timer on this fast-track to Friday: > > 1. we will be writing an opinion for the junit case, 2008/633, and the > content will impact the location of your deliverables. We are talking > about putting all java tools into /usr/share/lib/java, but the > discussion is not finished. > > 2. we are curious about the programmatic interface for findbugs, and if > that is available in this project. If so, it needs to be an exported > interface; if not, other ARC members would like to know why it's not > available. > > I'm sure more email is forthcoming :-) > Thanks, > -tdc > > > On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: > >> I disagree. The incremental advantage of using a slightly later >> version than the one installed is unlikely to persuade developers to >> download a later one. Looking the changelog for findbugs, the features >> are evolutionary, not revolutionary from one rev to the next. >> >> Lloyd Chambers wrote: >>> Petr, >>> From my viewpoint as a developer, I'm prepared to download the >>> current version, which I want preferentially because it will have the >>> latest goodies. I'm not all that interested in having a >>> pre-installed versions, because I can just as well keep my own >>> version of choice around. So from my point of view, I just don't see >>> the value. >>> In short, who is the "customer"? Developers probably won't care. In >>> fact, if the version is aggressively moved forward, it may be a >>> nuisance more than anything else (eg paths). >>> Which leads me to another "customer": QA. These folks might want a >>> specific version. So unless we can support more than one version, QA >>> is probably going to keep their own copies around. >>> So who is the customer here? And why would they care? >>> Lloyd >>> ............................................. >>> Lloyd Chambers >>> lloyd.chambers@sun.com >>> GlassFish team, LSARC member >>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>> Tom Childers wrote: >>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>> >>>>>> If frequency of release of the upstream project is a component of >>>>>> the ARC's >>>>>> decision to accept or reject said project, then those guidelines >>>>>> should be >>>>>> recorded somewhere. We have seen other FOSS cases which admit to >>>>>> porting the >>>>>> version which was current at the time of the OSR but are out of >>>>>> date by the >>>>>> time the ARC cases are submitted. >>>>> >>>>> Obviously, this is not a part of ARC guidelines. But the question >>>>> remains, how will the project team keep up the frequent release >>>>> schedule? And support multiple versions, since there seems to be >>>>> some dependency between test cases and junit releases? I agree that >>>>> we have absolutely seen other ARC cases where this becomes a major >>>>> issue; if we are going to create this dependency, how will we >>>>> address the issue? >>>>> -tdc >>>> >>>> We do not plan to support multiple versions. We may change it if it >>>> is a requirement. >>>> So is it usual that developer needs to have more versions of >>>> findbugs installed? >>>> Can you describe the dependency between test cases and junit releases? >>>> >>>> Thanks! >>>> >>>> Petr >> >> -- >> blu >> >> "Murderous organizations have increased in size and scope; they are >> more daring, they are served by the most terrible weapons offered by >> modern science, and the world is nowadays threatened by new forces >> which, if recklessly unchained, may some day wreck universal >> destruction." - Arthur Griffith, 1898 >> ---------------------------------------------------------------------- >> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From brian.utterback@sun.com Wed Oct 29 10:54:05 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9THs5UJ017921 for ; Wed, 29 Oct 2008 10:54:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9THs21x000335; Wed, 29 Oct 2008 10:54:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9I00M11HQ3BT00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 29 Oct 2008 10:54:04 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9I00AATHQ3RT70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 29 Oct 2008 10:54:03 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9THs0bv014478; Wed, 29 Oct 2008 13:54:01 -0400 (EDT) Date: Wed, 29 Oct 2008 13:54:00 -0400 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: To: Tom Childers Cc: Petr Slechta , Dean Roehrich , lsarc-ext@sun.com Message-id: <4908A338.8030108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> User-Agent: Thunderbird 2.0.0.18pre (X11/20081021) Status: RO Content-Length: 6377 I was not involved in the prior Junit discussions. Can someone tell me what the planned method of dealing with layered Java packages is going to be? Would it be acceptable to install into /usr/findbugs-1.3.6 with a symbolic link from /usr/bin/findbugs to /usr/findbugs-1.3.6/bin/findbugs? As to the API, looking at the findbugs site, it appears to be an incidental thing. It is not mentioned in the manual on the website. I suspect that it exists primarily as a method of creating plugins for various IDE's. Since the jar file will be delivered, so too will the API be available. But since it does not have any documentation provided in the standard installation package, neither would we deliver such. Of course, having a version number on the directory makes everything but the command line essentially uncommitted interfaces, since they will not be changing in place but might not be included in the future. Is that the expected situation with the proposed versioning, assuming that what I outlined is the proposed plan? The timer was extended until Friday on this case to match the timer for the Junit case, but if we don't get direction as to what the Junit case will document, obviously we will not be able to provide an updated spec by then. I think the project team is amenable to any reasonable plan, but they do need to know what the plan should be. Tom Childers wrote: > Brian, > > We discussed this case, and the junit case, in our OpenARC meeting this > morning. We are extending the timer on this fast-track to Friday: > > 1. we will be writing an opinion for the junit case, 2008/633, and the > content will impact the location of your deliverables. We are talking > about putting all java tools into /usr/share/lib/java, but the > discussion is not finished. > > 2. we are curious about the programmatic interface for findbugs, and if > that is available in this project. If so, it needs to be an exported > interface; if not, other ARC members would like to know why it's not > available. > > I'm sure more email is forthcoming :-) > Thanks, > -tdc > > > On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: > >> I disagree. The incremental advantage of using a slightly later >> version than the one installed is unlikely to persuade developers to >> download a later one. Looking the changelog for findbugs, the features >> are evolutionary, not revolutionary from one rev to the next. >> >> Lloyd Chambers wrote: >>> Petr, >>> From my viewpoint as a developer, I'm prepared to download the >>> current version, which I want preferentially because it will have the >>> latest goodies. I'm not all that interested in having a >>> pre-installed versions, because I can just as well keep my own >>> version of choice around. So from my point of view, I just don't see >>> the value. >>> In short, who is the "customer"? Developers probably won't care. In >>> fact, if the version is aggressively moved forward, it may be a >>> nuisance more than anything else (eg paths). >>> Which leads me to another "customer": QA. These folks might want a >>> specific version. So unless we can support more than one version, QA >>> is probably going to keep their own copies around. >>> So who is the customer here? And why would they care? >>> Lloyd >>> ............................................. >>> Lloyd Chambers >>> lloyd.chambers@sun.com >>> GlassFish team, LSARC member >>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>> Tom Childers wrote: >>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>> >>>>>> If frequency of release of the upstream project is a component of >>>>>> the ARC's >>>>>> decision to accept or reject said project, then those guidelines >>>>>> should be >>>>>> recorded somewhere. We have seen other FOSS cases which admit to >>>>>> porting the >>>>>> version which was current at the time of the OSR but are out of >>>>>> date by the >>>>>> time the ARC cases are submitted. >>>>> >>>>> Obviously, this is not a part of ARC guidelines. But the question >>>>> remains, how will the project team keep up the frequent release >>>>> schedule? And support multiple versions, since there seems to be >>>>> some dependency between test cases and junit releases? I agree that >>>>> we have absolutely seen other ARC cases where this becomes a major >>>>> issue; if we are going to create this dependency, how will we >>>>> address the issue? >>>>> -tdc >>>> >>>> We do not plan to support multiple versions. We may change it if it >>>> is a requirement. >>>> So is it usual that developer needs to have more versions of >>>> findbugs installed? >>>> Can you describe the dependency between test cases and junit releases? >>>> >>>> Thanks! >>>> >>>> Petr >> >> -- >> blu >> >> "Murderous organizations have increased in size and scope; they are >> more daring, they are served by the most terrible weapons offered by >> modern science, and the world is nowadays threatened by new forces >> which, if recklessly unchained, may some day wreck universal >> destruction." - Arthur Griffith, 1898 >> ---------------------------------------------------------------------- >> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Petr.Slechta@sun.com Mon Nov 3 01:50:35 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA39oYpt009702 for ; Mon, 3 Nov 2008 01:50:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mA39oOXE002061 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 3 Nov 2008 17:50:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R004074O76P00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 03 Nov 2008 01:50:31 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R00HKD4O6OS40@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 03 Nov 2008 01:50:30 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA39oTpI026576 for ; Mon, 03 Nov 2008 09:50:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00A0148I4S00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 03 Nov 2008 09:50:29 +0000 (GMT) Received: from [129.157.21.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R00GZC4NXC2C0@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 03 Nov 2008 09:50:21 +0000 (GMT) Date: Mon, 03 Nov 2008 10:50:24 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4908A338.8030108@sun.com> Sender: Petr.Slechta@sun.com To: Brian Utterback Cc: Tom Childers , Dean Roehrich , lsarc-ext@sun.com Message-id: <490EC960.8080205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 6238 Hello Brian and everybody, what is the current status of FindBugs ARC? Is there any decision/recommendation how to handle Java apps on OpenSolaris? Thanks! Petr Brian Utterback wrote: > I was not involved in the prior Junit discussions. Can someone tell me > what the planned method of dealing with layered Java packages is going > to be? Would it be acceptable to install into /usr/findbugs-1.3.6 with > a symbolic link from /usr/bin/findbugs to > /usr/findbugs-1.3.6/bin/findbugs? > > As to the API, looking at the findbugs site, it appears to be an > incidental thing. It is not mentioned in the manual on the website. I > suspect that it exists primarily as a method of creating plugins for > various IDE's. > > Since the jar file will be delivered, so too will the API be > available. But since it does not have any documentation provided in > the standard installation package, neither would we deliver such. > > Of course, having a version number on the directory makes everything > but the command line essentially uncommitted interfaces, since they > will not be changing in place but might not be included in the future. > Is that the expected situation with the proposed versioning, assuming > that what I outlined is the proposed plan? > > The timer was extended until Friday on this case to match the timer > for the Junit case, but if we don't get direction as to what the Junit > case will document, obviously we will not be able to provide an > updated spec by then. > > I think the project team is amenable to any reasonable plan, but they > do need to know what the plan should be. > > Tom Childers wrote: >> Brian, >> >> We discussed this case, and the junit case, in our OpenARC meeting >> this morning. We are extending the timer on this fast-track to Friday: >> >> 1. we will be writing an opinion for the junit case, 2008/633, and >> the content will impact the location of your deliverables. We are >> talking about putting all java tools into /usr/share/lib/java, but >> the discussion is not finished. >> >> 2. we are curious about the programmatic interface for findbugs, and >> if that is available in this project. If so, it needs to be an >> exported interface; if not, other ARC members would like to know why >> it's not available. >> >> I'm sure more email is forthcoming :-) >> Thanks, >> -tdc >> >> >> On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: >> >>> I disagree. The incremental advantage of using a slightly later >>> version than the one installed is unlikely to persuade developers to >>> download a later one. Looking the changelog for findbugs, the >>> features are evolutionary, not revolutionary from one rev to the next. >>> >>> Lloyd Chambers wrote: >>>> Petr, >>>> From my viewpoint as a developer, I'm prepared to download the >>>> current version, which I want preferentially because it will have >>>> the latest goodies. I'm not all that interested in having a >>>> pre-installed versions, because I can just as well keep my own >>>> version of choice around. So from my point of view, I just don't >>>> see the value. >>>> In short, who is the "customer"? Developers probably won't care. >>>> In fact, if the version is aggressively moved forward, it may be a >>>> nuisance more than anything else (eg paths). >>>> Which leads me to another "customer": QA. These folks might want a >>>> specific version. So unless we can support more than one version, >>>> QA is probably going to keep their own copies around. >>>> So who is the customer here? And why would they care? >>>> Lloyd >>>> ............................................. >>>> Lloyd Chambers >>>> lloyd.chambers@sun.com >>>> GlassFish team, LSARC member >>>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>>> Tom Childers wrote: >>>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>>> >>>>>>> If frequency of release of the upstream project is a component >>>>>>> of the ARC's >>>>>>> decision to accept or reject said project, then those guidelines >>>>>>> should be >>>>>>> recorded somewhere. We have seen other FOSS cases which admit >>>>>>> to porting the >>>>>>> version which was current at the time of the OSR but are out of >>>>>>> date by the >>>>>>> time the ARC cases are submitted. >>>>>> >>>>>> Obviously, this is not a part of ARC guidelines. But the question >>>>>> remains, how will the project team keep up the frequent release >>>>>> schedule? And support multiple versions, since there seems to be >>>>>> some dependency between test cases and junit releases? I agree >>>>>> that we have absolutely seen other ARC cases where this becomes a >>>>>> major issue; if we are going to create this dependency, how will >>>>>> we address the issue? >>>>>> -tdc >>>>> >>>>> We do not plan to support multiple versions. We may change it if >>>>> it is a requirement. >>>>> So is it usual that developer needs to have more versions of >>>>> findbugs installed? >>>>> Can you describe the dependency between test cases and junit >>>>> releases? >>>>> >>>>> Thanks! >>>>> >>>>> Petr >>> >>> -- >>> blu >>> >>> "Murderous organizations have increased in size and scope; they are >>> more daring, they are served by the most terrible weapons offered by >>> modern science, and the world is nowadays threatened by new forces >>> which, if recklessly unchained, may some day wreck universal >>> destruction." - Arthur Griffith, 1898 >>> ---------------------------------------------------------------------- >>> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >>> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom >> > From tom.childers@sun.com Tue Nov 18 10:19:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAIIJT7A003912 for ; Tue, 18 Nov 2008 10:19:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mAIIJKlQ026138 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 18 Nov 2008 11:19:29 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAJ0041FK8GC500@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 18 Nov 2008 10:19:28 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAJ00CW5K8EX0B0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 18 Nov 2008 10:19:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAIIJQrb029694 for ; Tue, 18 Nov 2008 10:19:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAJ00J01K0MGV00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 18 Nov 2008 10:19:26 -0800 (PST) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAJ006CSK7M05C0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 18 Nov 2008 10:18:58 -0800 (PST) Date: Tue, 18 Nov 2008 10:19:00 -0800 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <490EC960.8080205@sun.com> Sender: Thomas.Childers@sun.com To: Petr Slechta , Brian Utterback Cc: Dean Roehrich , LSARC-ext@sun.com Message-id: <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> Status: RO Content-Length: 6894 Hello, Petr and Brian. We have a solution. Please place the jar file and link in /usr/share/ lib/java. /usr/share/lib/java/findbugs.jar, which links to /usr/share/lib/java/indbugs-1.3.6.jar Can you please update the man page, FOSS checklist (section 4) and one- pager document? Once this has been done, we can approve this case. Thanks, -tdc On Nov 3, 2008, at 1:50 AM, Petr Slechta wrote: > Hello Brian and everybody, > > what is the current status of FindBugs ARC? Is there any decision/ > recommendation how to handle Java apps on OpenSolaris? > > Thanks! > > Petr > > Brian Utterback wrote: >> I was not involved in the prior Junit discussions. Can someone tell >> me what the planned method of dealing with layered Java packages is >> going to be? Would it be acceptable to install into /usr/ >> findbugs-1.3.6 with a symbolic link from /usr/bin/findbugs to /usr/ >> findbugs-1.3.6/bin/findbugs? >> >> As to the API, looking at the findbugs site, it appears to be an >> incidental thing. It is not mentioned in the manual on the website. >> I suspect that it exists primarily as a method of creating plugins >> for various IDE's. >> >> Since the jar file will be delivered, so too will the API be >> available. But since it does not have any documentation provided in >> the standard installation package, neither would we deliver such. >> >> Of course, having a version number on the directory makes >> everything but the command line essentially uncommitted interfaces, >> since they will not be changing in place but might not be included >> in the future. Is that the expected situation with the proposed >> versioning, assuming that what I outlined is the proposed plan? >> >> The timer was extended until Friday on this case to match the timer >> for the Junit case, but if we don't get direction as to what the >> Junit case will document, obviously we will not be able to provide >> an updated spec by then. >> >> I think the project team is amenable to any reasonable plan, but >> they do need to know what the plan should be. >> >> Tom Childers wrote: >>> Brian, >>> >>> We discussed this case, and the junit case, in our OpenARC meeting >>> this morning. We are extending the timer on this fast-track to >>> Friday: >>> >>> 1. we will be writing an opinion for the junit case, 2008/633, and >>> the content will impact the location of your deliverables. We are >>> talking about putting all java tools into /usr/share/lib/java, but >>> the discussion is not finished. >>> >>> 2. we are curious about the programmatic interface for findbugs, >>> and if that is available in this project. If so, it needs to be an >>> exported interface; if not, other ARC members would like to know >>> why it's not available. >>> >>> I'm sure more email is forthcoming :-) >>> Thanks, >>> -tdc >>> >>> >>> On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: >>> >>>> I disagree. The incremental advantage of using a slightly later >>>> version than the one installed is unlikely to persuade developers >>>> to download a later one. Looking the changelog for findbugs, the >>>> features are evolutionary, not revolutionary from one rev to the >>>> next. >>>> >>>> Lloyd Chambers wrote: >>>>> Petr, >>>>> From my viewpoint as a developer, I'm prepared to download the >>>>> current version, which I want preferentially because it will >>>>> have the latest goodies. I'm not all that interested in having >>>>> a pre-installed versions, because I can just as well keep my own >>>>> version of choice around. So from my point of view, I just >>>>> don't see the value. >>>>> In short, who is the "customer"? Developers probably won't >>>>> care. In fact, if the version is aggressively moved forward, it >>>>> may be a nuisance more than anything else (eg paths). >>>>> Which leads me to another "customer": QA. These folks might >>>>> want a specific version. So unless we can support more than one >>>>> version, QA is probably going to keep their own copies around. >>>>> So who is the customer here? And why would they care? >>>>> Lloyd >>>>> ............................................. >>>>> Lloyd Chambers >>>>> lloyd.chambers@sun.com >>>>> GlassFish team, LSARC member >>>>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>>>> Tom Childers wrote: >>>>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>>>> >>>>>>>> If frequency of release of the upstream project is a >>>>>>>> component of the ARC's >>>>>>>> decision to accept or reject said project, then those >>>>>>>> guidelines should be >>>>>>>> recorded somewhere. We have seen other FOSS cases which >>>>>>>> admit to porting the >>>>>>>> version which was current at the time of the OSR but are out >>>>>>>> of date by the >>>>>>>> time the ARC cases are submitted. >>>>>>> >>>>>>> Obviously, this is not a part of ARC guidelines. But the >>>>>>> question remains, how will the project team keep up the >>>>>>> frequent release schedule? And support multiple versions, >>>>>>> since there seems to be some dependency between test cases and >>>>>>> junit releases? I agree that we have absolutely seen other ARC >>>>>>> cases where this becomes a major issue; if we are going to >>>>>>> create this dependency, how will we address the issue? >>>>>>> -tdc >>>>>> >>>>>> We do not plan to support multiple versions. We may change it >>>>>> if it is a requirement. >>>>>> So is it usual that developer needs to have more versions of >>>>>> findbugs installed? >>>>>> Can you describe the dependency between test cases and junit >>>>>> releases? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Petr >>>> >>>> -- >>>> blu >>>> >>>> "Murderous organizations have increased in size and scope; they are >>>> more daring, they are served by the most terrible weapons offered >>>> by >>>> modern science, and the world is nowadays threatened by new forces >>>> which, if recklessly unchained, may some day wreck universal >>>> destruction." - Arthur Griffith, 1898 >>>> ---------------------------------------------------------------------- >>>> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >>>> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom >>> >> > From Petr.Slechta@sun.com Wed Nov 19 01:53:45 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJ9rjrv009948 for ; Wed, 19 Nov 2008 01:53:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mAJ9rhCO018392 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 19 Nov 2008 01:53:45 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAK00L1FRHLHG00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Nov 2008 02:53:45 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAK00FKZRHKC340@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Nov 2008 02:53:45 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAJ9rip1022376 for ; Wed, 19 Nov 2008 09:53:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAK00D01QJFE600@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Nov 2008 09:53:44 +0000 (GMT) Received: from [10.162.9.75] ([85.160.2.27]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAK000BDRGSICF0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Nov 2008 09:53:19 +0000 (GMT) Date: Wed, 19 Nov 2008 10:53:20 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> Sender: Petr.Slechta@sun.com To: Tom Childers Cc: Brian Utterback , Dean Roehrich , LSARC-ext@sun.com Message-id: <4923E210.6030803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 10330 Hello all, I want to be clear about installation structure of findbugs. The original proposal was: (please pay special attention on /usr/share/java/findbugs/* files) --- /usr/bin/findbugs /usr/share/applications/jpackage-findbugs.desktop /usr/share/doc/findbugs /usr/share/doc/findbugs/LICENSE.txt /usr/share/doc/findbugs/README.txt /usr/share/doc/findbugs/design /usr/share/doc/findbugs/design/DecouplingFromBCEL.txt /usr/share/doc/findbugs/design/VisitingAndCaching.txt /usr/share/doc/findbugs/design/architecture /usr/share/doc/findbugs/design/architecture/Makefile /usr/share/doc/findbugs/design/architecture/architecture.tex /usr/share/doc/findbugs/design/architecture/attention.pdf /usr/share/doc/findbugs/design/architecture/attention.svg /usr/share/doc/findbugs/design/architecture/mkdep.pl /usr/share/doc/findbugs/design/eclipse findbugs plugin features.sxw /usr/share/findbugs-1.3.4 /usr/share/findbugs-1.3.4/bin /usr/share/findbugs-1.3.4/bin/addMessages /usr/share/findbugs-1.3.4/bin/computeBugHistory /usr/share/findbugs-1.3.4/bin/convertXmlToText /usr/share/findbugs-1.3.4/bin/copyBuggySource /usr/share/findbugs-1.3.4/bin/defectDensity /usr/share/findbugs-1.3.4/bin/deprecated /usr/share/findbugs-1.3.4/bin/deprecated/bugHistory /usr/share/findbugs-1.3.4/bin/deprecated/unionBugs /usr/share/findbugs-1.3.4/bin/deprecated/unionResults /usr/share/findbugs-1.3.4/bin/deprecated/updateBugs /usr/share/findbugs-1.3.4/bin/fbwrap /usr/share/findbugs-1.3.4/bin/filterBugs /usr/share/findbugs-1.3.4/bin/findbugs /usr/share/findbugs-1.3.4/bin/listBugDatabaseInfo /usr/share/findbugs-1.3.4/bin/mineBugHistory /usr/share/findbugs-1.3.4/bin/printAppVersion /usr/share/findbugs-1.3.4/bin/printClass /usr/share/findbugs-1.3.4/bin/rejarForAnalysis /usr/share/findbugs-1.3.4/bin/setBugDatabaseInfo /usr/share/findbugs-1.3.4/bin/unionBugs /usr/share/findbugs-1.3.4/bin/xpathFind /usr/share/icons/hicolor/16x16/apps/findbugs.png /usr/share/icons/hicolor/32x32/apps/findbugs.png /usr/share/icons/hicolor/48x48/apps/findbugs.png /usr/share/java/findbugs/lib/annotations-1.3.4.jar /usr/share/java/findbugs/lib/annotations.jar /usr/share/java/findbugs/lib/asm3-commons.jar /usr/share/java/findbugs/lib/asm3-tree.jar /usr/share/java/findbugs/lib/asm3.jar /usr/share/java/findbugs/lib/bcel5.3.jar /usr/share/java/findbugs/lib/dom4j.jar /usr/share/java/findbugs/lib/findbugs-1.3.4.jar /usr/share/java/findbugs/lib/findbugs-ant-1.3.4.jar /usr/share/java/findbugs/lib/findbugs-ant.jar /usr/share/java/findbugs/lib/findbugs.jar /usr/share/java/findbugs/lib/findbugsGUI-1.3.4.jar /usr/share/java/findbugs/lib/findbugsGUI.jar /usr/share/java/findbugs/lib/jaxen.jar /usr/share/java/findbugs/lib/jcip-annotations.jar /usr/share/java/findbugs/lib/jsr-305.jar /usr/share/java/findbugs/plugin /usr/share/java/findbugs/plugin/coreplugin.jar /usr/share/pixmaps/findbugs.png --- So should I change the section to: /usr/share/lib/java/annotations-1.3.4.jar /usr/share/lib/java/annotations.jar /usr/share/lib/java/asm3-commons.jar ... /usr/share/lib/java/findbugs-1.3.4.jar etc. plus /usr/share/lib/java/findbugs.jar -> /usr/share/lib/java/findbugs-1.3.4.jar Won't be there clashing with jars from other components? Please confirm installation structure of findbugs so I can move forward. Thanks! Petr Tom Childers wrote: > Hello, Petr and Brian. > > We have a solution. Please place the jar file and link in > /usr/share/lib/java. > > /usr/share/lib/java/findbugs.jar, which links to > /usr/share/lib/java/indbugs-1.3.6.jar > > Can you please update the man page, FOSS checklist (section 4) and > one-pager document? Once this has been done, we can approve this case. > > Thanks, > -tdc > > > On Nov 3, 2008, at 1:50 AM, Petr Slechta wrote: > >> Hello Brian and everybody, >> >> what is the current status of FindBugs ARC? Is there any >> decision/recommendation how to handle Java apps on OpenSolaris? >> >> Thanks! >> >> Petr >> >> Brian Utterback wrote: >>> I was not involved in the prior Junit discussions. Can someone tell >>> me what the planned method of dealing with layered Java packages is >>> going to be? Would it be acceptable to install into >>> /usr/findbugs-1.3.6 with a symbolic link from /usr/bin/findbugs to >>> /usr/findbugs-1.3.6/bin/findbugs? >>> >>> As to the API, looking at the findbugs site, it appears to be an >>> incidental thing. It is not mentioned in the manual on the website. >>> I suspect that it exists primarily as a method of creating plugins >>> for various IDE's. >>> >>> Since the jar file will be delivered, so too will the API be >>> available. But since it does not have any documentation provided in >>> the standard installation package, neither would we deliver such. >>> >>> Of course, having a version number on the directory makes everything >>> but the command line essentially uncommitted interfaces, since they >>> will not be changing in place but might not be included in the >>> future. Is that the expected situation with the proposed >>> versioning, assuming that what I outlined is the proposed plan? >>> >>> The timer was extended until Friday on this case to match the timer >>> for the Junit case, but if we don't get direction as to what the >>> Junit case will document, obviously we will not be able to provide >>> an updated spec by then. >>> >>> I think the project team is amenable to any reasonable plan, but >>> they do need to know what the plan should be. >>> >>> Tom Childers wrote: >>>> Brian, >>>> >>>> We discussed this case, and the junit case, in our OpenARC meeting >>>> this morning. We are extending the timer on this fast-track to >>>> Friday: >>>> >>>> 1. we will be writing an opinion for the junit case, 2008/633, and >>>> the content will impact the location of your deliverables. We are >>>> talking about putting all java tools into /usr/share/lib/java, but >>>> the discussion is not finished. >>>> >>>> 2. we are curious about the programmatic interface for findbugs, >>>> and if that is available in this project. If so, it needs to be an >>>> exported interface; if not, other ARC members would like to know >>>> why it's not available. >>>> >>>> I'm sure more email is forthcoming :-) >>>> Thanks, >>>> -tdc >>>> >>>> >>>> On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: >>>> >>>>> I disagree. The incremental advantage of using a slightly later >>>>> version than the one installed is unlikely to persuade developers >>>>> to download a later one. Looking the changelog for findbugs, the >>>>> features are evolutionary, not revolutionary from one rev to the >>>>> next. >>>>> >>>>> Lloyd Chambers wrote: >>>>>> Petr, >>>>>> From my viewpoint as a developer, I'm prepared to download the >>>>>> current version, which I want preferentially because it will have >>>>>> the latest goodies. I'm not all that interested in having a >>>>>> pre-installed versions, because I can just as well keep my own >>>>>> version of choice around. So from my point of view, I just don't >>>>>> see the value. >>>>>> In short, who is the "customer"? Developers probably won't care. >>>>>> In fact, if the version is aggressively moved forward, it may be >>>>>> a nuisance more than anything else (eg paths). >>>>>> Which leads me to another "customer": QA. These folks might want >>>>>> a specific version. So unless we can support more than one >>>>>> version, QA is probably going to keep their own copies around. >>>>>> So who is the customer here? And why would they care? >>>>>> Lloyd >>>>>> ............................................. >>>>>> Lloyd Chambers >>>>>> lloyd.chambers@sun.com >>>>>> GlassFish team, LSARC member >>>>>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>>>>> Tom Childers wrote: >>>>>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>>>>> >>>>>>>>> If frequency of release of the upstream project is a component >>>>>>>>> of the ARC's >>>>>>>>> decision to accept or reject said project, then those >>>>>>>>> guidelines should be >>>>>>>>> recorded somewhere. We have seen other FOSS cases which admit >>>>>>>>> to porting the >>>>>>>>> version which was current at the time of the OSR but are out >>>>>>>>> of date by the >>>>>>>>> time the ARC cases are submitted. >>>>>>>> >>>>>>>> Obviously, this is not a part of ARC guidelines. But the >>>>>>>> question remains, how will the project team keep up the >>>>>>>> frequent release schedule? And support multiple versions, since >>>>>>>> there seems to be some dependency between test cases and junit >>>>>>>> releases? I agree that we have absolutely seen other ARC cases >>>>>>>> where this becomes a major issue; if we are going to create >>>>>>>> this dependency, how will we address the issue? >>>>>>>> -tdc >>>>>>> >>>>>>> We do not plan to support multiple versions. We may change it if >>>>>>> it is a requirement. >>>>>>> So is it usual that developer needs to have more versions of >>>>>>> findbugs installed? >>>>>>> Can you describe the dependency between test cases and junit >>>>>>> releases? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Petr >>>>> >>>>> -- >>>>> blu >>>>> >>>>> "Murderous organizations have increased in size and scope; they are >>>>> more daring, they are served by the most terrible weapons offered by >>>>> modern science, and the world is nowadays threatened by new forces >>>>> which, if recklessly unchained, may some day wreck universal >>>>> destruction." - Arthur Griffith, 1898 >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >>>>> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom >>>> >>> >> > From tom.childers@sun.com Tue Dec 9 11:01:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB9J1lUe009045 for ; Tue, 9 Dec 2008 11:01:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB9J1i2e028132 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 9 Dec 2008 19:01:46 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBM00903I6XOR00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 11:01:45 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBM003T0I6WXG70@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 11:01:44 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB9J1ibq006977 for ; Tue, 09 Dec 2008 11:01:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBM00801H9JXS00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 11:01:44 -0800 (PST) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBM00MZII6JMNC0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 11:01:32 -0800 (PST) Date: Tue, 09 Dec 2008 11:01:31 -0800 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4923E210.6030803@sun.com> Sender: Thomas.Childers@sun.com To: LSARC-ext@sun.com Cc: Brian Utterback , Dean Roehrich , Petr Slechta Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <2C521D79-1D31-4CA3-91D2-6F9E732E46EC@sun.com> <20081021185444.GA23008@kickball-mn.Central.Sun.COM> <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> Status: RO Content-Length: 12479 LSARC members, Looking at this case, which has been sitting for a couple of weeks, I realize that Petr has raised an issue that we need to clarify. If we use links in /usr/share/java to point to the most recent version of each component, and underlying components can be delivered by different packages, then links may get changed and cause things to break. Can we simply assume that IPS handles this situation correctly? If so, are we requiring that all of these FOSS projects going into OpenSolaris use IPS? Here are details. Originally, findbugs was going to install into /usr/ share/java/findbugs, viz: /usr/share/java/findbugs/lib/annotations-1.3.4.jar /usr/share/java/findbugs/lib/annotations.jar, links to the annotations-1.3.4 jar /usr/share/java/findbugs/lib/findbugs-1.3.4.jar /usr/share/java/findbugs/lib/findbugs.jar, links to the findbugs-1.3.4 jar ...etc. We asked the team to adopt the convention established for junit, LSARC/ 2008/633, similar to /usr/lib: /usr/share/lib/java/junit.jar link to most recent version /usr/share/lib/java/junit-4.5.jar /usr/share/lib/java/junit-3.8.2.jar ...etc. However, if they place all the findbugs pieces, like annotations-1.3.4.jar, in /usr/share/lib/java, then we have the situation that multiple projects who require and deliver the same component can overwrite each other. annotations.jar could be changed to link to a different version, breaking the functionality of something that is already installed. OpenSolaris folks, please let me know if this is handled already, so we can close this case. -tdc On Nov 19, 2008, at 1:53 AM, Petr Slechta wrote: > Hello all, > > I want to be clear about installation structure of findbugs. > > The original proposal was: (please pay special attention on /usr/ > share/java/findbugs/* files) > > --- > /usr/bin/findbugs > /usr/share/applications/jpackage-findbugs.desktop > /usr/share/doc/findbugs > /usr/share/doc/findbugs/LICENSE.txt > /usr/share/doc/findbugs/README.txt > /usr/share/doc/findbugs/design > /usr/share/doc/findbugs/design/DecouplingFromBCEL.txt > /usr/share/doc/findbugs/design/VisitingAndCaching.txt > /usr/share/doc/findbugs/design/architecture > /usr/share/doc/findbugs/design/architecture/Makefile > /usr/share/doc/findbugs/design/architecture/architecture.tex > /usr/share/doc/findbugs/design/architecture/attention.pdf > /usr/share/doc/findbugs/design/architecture/attention.svg > /usr/share/doc/findbugs/design/architecture/mkdep.pl > /usr/share/doc/findbugs/design/eclipse findbugs plugin features.sxw > /usr/share/findbugs-1.3.4 > /usr/share/findbugs-1.3.4/bin > /usr/share/findbugs-1.3.4/bin/addMessages > /usr/share/findbugs-1.3.4/bin/computeBugHistory > /usr/share/findbugs-1.3.4/bin/convertXmlToText > /usr/share/findbugs-1.3.4/bin/copyBuggySource > /usr/share/findbugs-1.3.4/bin/defectDensity > /usr/share/findbugs-1.3.4/bin/deprecated > /usr/share/findbugs-1.3.4/bin/deprecated/bugHistory > /usr/share/findbugs-1.3.4/bin/deprecated/unionBugs > /usr/share/findbugs-1.3.4/bin/deprecated/unionResults > /usr/share/findbugs-1.3.4/bin/deprecated/updateBugs > /usr/share/findbugs-1.3.4/bin/fbwrap > /usr/share/findbugs-1.3.4/bin/filterBugs > /usr/share/findbugs-1.3.4/bin/findbugs > /usr/share/findbugs-1.3.4/bin/listBugDatabaseInfo > /usr/share/findbugs-1.3.4/bin/mineBugHistory > /usr/share/findbugs-1.3.4/bin/printAppVersion > /usr/share/findbugs-1.3.4/bin/printClass > /usr/share/findbugs-1.3.4/bin/rejarForAnalysis > /usr/share/findbugs-1.3.4/bin/setBugDatabaseInfo > /usr/share/findbugs-1.3.4/bin/unionBugs > /usr/share/findbugs-1.3.4/bin/xpathFind > /usr/share/icons/hicolor/16x16/apps/findbugs.png > /usr/share/icons/hicolor/32x32/apps/findbugs.png > /usr/share/icons/hicolor/48x48/apps/findbugs.png > > /usr/share/java/findbugs/lib/annotations-1.3.4.jar > /usr/share/java/findbugs/lib/annotations.jar > /usr/share/java/findbugs/lib/asm3-commons.jar > /usr/share/java/findbugs/lib/asm3-tree.jar > /usr/share/java/findbugs/lib/asm3.jar > /usr/share/java/findbugs/lib/bcel5.3.jar > /usr/share/java/findbugs/lib/dom4j.jar > /usr/share/java/findbugs/lib/findbugs-1.3.4.jar > /usr/share/java/findbugs/lib/findbugs-ant-1.3.4.jar > /usr/share/java/findbugs/lib/findbugs-ant.jar > /usr/share/java/findbugs/lib/findbugs.jar > /usr/share/java/findbugs/lib/findbugsGUI-1.3.4.jar > /usr/share/java/findbugs/lib/findbugsGUI.jar > /usr/share/java/findbugs/lib/jaxen.jar > /usr/share/java/findbugs/lib/jcip-annotations.jar > /usr/share/java/findbugs/lib/jsr-305.jar > /usr/share/java/findbugs/plugin > /usr/share/java/findbugs/plugin/coreplugin.jar > > /usr/share/pixmaps/findbugs.png > --- > > > So should I change the section to: > > /usr/share/lib/java/annotations-1.3.4.jar > /usr/share/lib/java/annotations.jar > /usr/share/lib/java/asm3-commons.jar > ... > /usr/share/lib/java/findbugs-1.3.4.jar > etc. > > plus > /usr/share/lib/java/findbugs.jar -> /usr/share/lib/java/ > findbugs-1.3.4.jar > > > Won't be there clashing with jars from other components? > > > Please confirm installation structure of findbugs so I can move > forward. > > Thanks! > > Petr > > > Tom Childers wrote: >> Hello, Petr and Brian. >> >> We have a solution. Please place the jar file and link in /usr/ >> share/lib/java. >> >> /usr/share/lib/java/findbugs.jar, which links to >> /usr/share/lib/java/indbugs-1.3.6.jar >> >> Can you please update the man page, FOSS checklist (section 4) and >> one-pager document? Once this has been done, we can approve this >> case. >> >> Thanks, >> -tdc >> >> >> On Nov 3, 2008, at 1:50 AM, Petr Slechta wrote: >> >>> Hello Brian and everybody, >>> >>> what is the current status of FindBugs ARC? Is there any decision/ >>> recommendation how to handle Java apps on OpenSolaris? >>> >>> Thanks! >>> >>> Petr >>> >>> Brian Utterback wrote: >>>> I was not involved in the prior Junit discussions. Can someone >>>> tell me what the planned method of dealing with layered Java >>>> packages is going to be? Would it be acceptable to install into / >>>> usr/findbugs-1.3.6 with a symbolic link from /usr/bin/findbugs >>>> to /usr/findbugs-1.3.6/bin/findbugs? >>>> >>>> As to the API, looking at the findbugs site, it appears to be an >>>> incidental thing. It is not mentioned in the manual on the >>>> website. I suspect that it exists primarily as a method of >>>> creating plugins for various IDE's. >>>> >>>> Since the jar file will be delivered, so too will the API be >>>> available. But since it does not have any documentation provided >>>> in the standard installation package, neither would we deliver >>>> such. >>>> >>>> Of course, having a version number on the directory makes >>>> everything but the command line essentially uncommitted >>>> interfaces, since they will not be changing in place but might >>>> not be included in the future. Is that the expected situation >>>> with the proposed versioning, assuming that what I outlined is >>>> the proposed plan? >>>> >>>> The timer was extended until Friday on this case to match the >>>> timer for the Junit case, but if we don't get direction as to >>>> what the Junit case will document, obviously we will not be able >>>> to provide an updated spec by then. >>>> >>>> I think the project team is amenable to any reasonable plan, but >>>> they do need to know what the plan should be. >>>> >>>> Tom Childers wrote: >>>>> Brian, >>>>> >>>>> We discussed this case, and the junit case, in our OpenARC >>>>> meeting this morning. We are extending the timer on this fast- >>>>> track to Friday: >>>>> >>>>> 1. we will be writing an opinion for the junit case, 2008/633, >>>>> and the content will impact the location of your deliverables. >>>>> We are talking about putting all java tools into /usr/share/lib/ >>>>> java, but the discussion is not finished. >>>>> >>>>> 2. we are curious about the programmatic interface for findbugs, >>>>> and if that is available in this project. If so, it needs to be >>>>> an exported interface; if not, other ARC members would like to >>>>> know why it's not available. >>>>> >>>>> I'm sure more email is forthcoming :-) >>>>> Thanks, >>>>> -tdc >>>>> >>>>> >>>>> On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: >>>>> >>>>>> I disagree. The incremental advantage of using a slightly later >>>>>> version than the one installed is unlikely to persuade >>>>>> developers to download a later one. Looking the changelog for >>>>>> findbugs, the features are evolutionary, not revolutionary from >>>>>> one rev to the next. >>>>>> >>>>>> Lloyd Chambers wrote: >>>>>>> Petr, >>>>>>> From my viewpoint as a developer, I'm prepared to download the >>>>>>> current version, which I want preferentially because it will >>>>>>> have the latest goodies. I'm not all that interested in >>>>>>> having a pre-installed versions, because I can just as well >>>>>>> keep my own version of choice around. So from my point of >>>>>>> view, I just don't see the value. >>>>>>> In short, who is the "customer"? Developers probably won't >>>>>>> care. In fact, if the version is aggressively moved forward, >>>>>>> it may be a nuisance more than anything else (eg paths). >>>>>>> Which leads me to another "customer": QA. These folks might >>>>>>> want a specific version. So unless we can support more than >>>>>>> one version, QA is probably going to keep their own copies >>>>>>> around. >>>>>>> So who is the customer here? And why would they care? >>>>>>> Lloyd >>>>>>> ............................................. >>>>>>> Lloyd Chambers >>>>>>> lloyd.chambers@sun.com >>>>>>> GlassFish team, LSARC member >>>>>>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>>>>>> Tom Childers wrote: >>>>>>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, 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@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. >>>>>>>>>> >>>>>>>>>> If frequency of release of the upstream project is a >>>>>>>>>> component of the ARC's >>>>>>>>>> decision to accept or reject said project, then those >>>>>>>>>> guidelines should be >>>>>>>>>> recorded somewhere. We have seen other FOSS cases which >>>>>>>>>> admit to porting the >>>>>>>>>> version which was current at the time of the OSR but are >>>>>>>>>> out of date by the >>>>>>>>>> time the ARC cases are submitted. >>>>>>>>> >>>>>>>>> Obviously, this is not a part of ARC guidelines. But the >>>>>>>>> question remains, how will the project team keep up the >>>>>>>>> frequent release schedule? And support multiple versions, >>>>>>>>> since there seems to be some dependency between test cases >>>>>>>>> and junit releases? I agree that we have absolutely seen >>>>>>>>> other ARC cases where this becomes a major issue; if we are >>>>>>>>> going to create this dependency, how will we address the >>>>>>>>> issue? >>>>>>>>> -tdc >>>>>>>> >>>>>>>> We do not plan to support multiple versions. We may change it >>>>>>>> if it is a requirement. >>>>>>>> So is it usual that developer needs to have more versions of >>>>>>>> findbugs installed? >>>>>>>> Can you describe the dependency between test cases and junit >>>>>>>> releases? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Petr >>>>>> >>>>>> -- >>>>>> blu >>>>>> >>>>>> "Murderous organizations have increased in size and scope; they >>>>>> are >>>>>> more daring, they are served by the most terrible weapons >>>>>> offered by >>>>>> modern science, and the world is nowadays threatened by new >>>>>> forces >>>>>> which, if recklessly unchained, may some day wreck universal >>>>>> destruction." - Arthur Griffith, 1898 >>>>>> ---------------------------------------------------------------------- >>>>>> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >>>>>> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom >>>>> >>>> >>> >> > From danek.duvall@sun.com Tue Dec 9 11:13:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB9JDGD2009281 for ; Tue, 9 Dec 2008 11:13:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mB9JDDpx003300; Wed, 10 Dec 2008 03:13:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBM00A0LIQ2B700@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Dec 2008 11:13:14 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBM003WCIQ2XG80@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Dec 2008 11:13:14 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB9JDCrJ048983; Tue, 09 Dec 2008 11:13:12 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB9JEjkH007662; Tue, 09 Dec 2008 11:14:45 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB9JEjb7007661; Tue, 09 Dec 2008 11:14:45 -0800 (PST) Date: Tue, 09 Dec 2008 11:14:45 -0800 From: Danek Duvall Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: To: Tom Childers Cc: LSARC-ext@sun.com, Brian Utterback , Dean Roehrich , Petr Slechta Message-id: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1047 On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: > Looking at this case, which has been sitting for a couple of weeks, I > realize that Petr has raised an issue that we need to clarify. If we use > links in /usr/share/java to point to the most recent version of each > component, and underlying components can be delivered by different > packages, then links may get changed and cause things to break. > > Can we simply assume that IPS handles this situation correctly? > If so, are we requiring that all of these FOSS projects going into > OpenSolaris use IPS? Those links need each to be delivered exactly once on a system, by just one package. No packaging system can deal with a single file being delivered multiple times by conflicting package developers. I'd suggest that projects either directly use the versioned jar file that's most appropriate for their needs, or install a symlink in a private directory to the jar file they need, and put that in their classpath. Perhaps there are other alternatives, too. Danek From john.plocher@gmail.com Tue Dec 9 16:05:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBA05XZf019822 for ; Tue, 9 Dec 2008 16:05:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBA05TRD006434 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 10 Dec 2008 00:05:32 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBM00303W974N00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 17:05:31 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBM00EZLW97BAA0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 09 Dec 2008 17:05:31 -0700 (MST) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by brmea-mail-3.sun.com (8.13.8+Sun/8.12.9) with ESMTP id mB9NxrR6005891 for ; Wed, 10 Dec 2008 00:05:31 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay21i.sun.com with ESMTP id BT-MMP-1073372 for LSARC-ext@sun.com; Wed, 10 Dec 2008 00:05:30 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-17054206 for LSARC-ext@sun.com; Wed, 10 Dec 2008 00:05:30 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.157] [74.125.46.157]) by relay24i.sun.com with ESMTP id BT-MMP-20948522 for LSARC-ext@sun.com; Wed, 10 Dec 2008 00:05:30 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 9so125135ywk.68 for ; Tue, 09 Dec 2008 16:04:40 -0800 (PST) Received: by 10.90.84.1 with SMTP id h1mr530078agb.70.1228867480168; Tue, 09 Dec 2008 16:04:40 -0800 (PST) Received: by 10.90.31.7 with HTTP; Tue, 09 Dec 2008 16:04:40 -0800 (PST) Date: Tue, 09 Dec 2008 16:04:40 -0800 From: John Plocher Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: To: Tom Childers Cc: LSARC-ext@sun.com, Dean Roehrich , Brian Utterback , Petr Slechta Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kkMkLIHZ0oYSNSm73+fyhoPWKm8kZ80OBCSbBnwjFoI=; b=pUM2KbgQaSXLA1WVs+WXHn7T8y/IbGogHb7y2CsA/TVJK5mwzkZjZ+SP4PZ2yecjyr gwGH6sbY3SZ8YBLkeeSqvpn1+edNxWrCOpJ4P3+z9iBamIYAbTDpr/vqEIeS5UWw9iVb SHLy/W4JPVnjSoPZ/igEZRn9Fu9mBRnDtpTgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=f2cU4vkZpSfV8ZbcWvTDyPEd1xehhJwhjpd+A2Qiq6R2jghIQHL0OC3XLcsE4c5GDJ ndCz4Gc1I8gzXlIzPUq9YzFj7NrSof+mT33GYqCkwWI7Z97YYWc9JG4HONtojL7CeJ3c 1kXCdRK6c5pN2vN/3ChoNc4eiDg5DKyOpZqxE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.068sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> Status: RO Content-Length: 2033 On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers wrote: >... then links may get changed and cause things to break. > We asked the team to adopt the convention established for junit, LSARC/ > 2008/633, similar to /usr/lib: > > /usr/share/lib/java/junit.jar link to most recent version > /usr/share/lib/java/junit-4.5.jar > /usr/share/lib/java/junit-3.8.2.jar > ...etc. > > However, if they place all the findbugs pieces, like > annotations-1.3.4.jar, in /usr/share/lib/java, then we have the > situation that multiple projects who require and deliver the same > component can overwrite each other. annotations.jar could be changed > to link to a different version, breaking the functionality of > something that is already installed. Shouldn't those depend directly on the versioned item and NOT on the convenience link? That is, if I depend on junit, I should either A) link to /usr/share/lib/java/junit.jar IFF the interface stability I care about is Committed, or B) link to /usr/share/lib/java/junit-4.5.jar if the interface stability is less stable If I link to "junit.jar", but junit's stability is, say, Volatile, then I have, as they say, just screwed up. If junit (the convenience link) evolves incompatibly out from under me, my application breaks immediately. Braap. Danek Duvall wrote: > Those links need each to be delivered exactly once on a system, by just one > package. +1 I'd add, that package is delivered by the team that "owns" junit, and they get to decide, based on the promises they made when exporting the junit interface stability, when and if the convenience link(s) should change. If they promised "Committed", then they *must* do the diligence to ensure that the new version of junit contains absolutely no incompatible changes. If they promised Committed, then I should be able to depend on it being Committed, and use of the convenience link is safe. Otherwise, for all of the perturbations of "otherwise", it isn't. -John From Petr.Slechta@sun.com Wed Dec 10 07:27:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBAFRiJY025345 for ; Wed, 10 Dec 2008 07:27:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBAFRSrm029923 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 10 Dec 2008 15:27:43 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBO00I0P2Y67T00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 10 Dec 2008 07:27:42 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO00BJT2Y59P40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 10 Dec 2008 07:27:42 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBAFRfD7006769 for ; Wed, 10 Dec 2008 15:27:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBO00K0129HZA00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 10 Dec 2008 15:27:41 +0000 (GMT) Received: from [129.157.21.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBO00GII2XRH880@fe-emea-10.sun.com>; Wed, 10 Dec 2008 15:27:27 +0000 (GMT) Date: Wed, 10 Dec 2008 16:27:26 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@sun.com To: Danek Duvall Cc: Tom Childers , lsarc-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <493FDFDE.3070700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 1486 Hello all LSARC members! Please let me know the final decision regarding the packaging structure of findbugs (or more generally of any Java application under OpenSolaris). This LSARC is running already for a long time and I need to move forward with my task. I would be happy to update my LSARC paper with the final solution. Thank you in advance! Petr Slechta Danek Duvall wrote: > On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: > > >> Looking at this case, which has been sitting for a couple of weeks, I >> realize that Petr has raised an issue that we need to clarify. If we use >> links in /usr/share/java to point to the most recent version of each >> component, and underlying components can be delivered by different >> packages, then links may get changed and cause things to break. >> >> Can we simply assume that IPS handles this situation correctly? >> If so, are we requiring that all of these FOSS projects going into >> OpenSolaris use IPS? >> > > Those links need each to be delivered exactly once on a system, by just one > package. No packaging system can deal with a single file being delivered > multiple times by conflicting package developers. > > I'd suggest that projects either directly use the versioned jar file that's > most appropriate for their needs, or install a symlink in a private > directory to the jar file they need, and put that in their classpath. > Perhaps there are other alternatives, too. > > Danek > From storycrafter@gmail.com Wed Dec 10 09:08:38 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBAH8cnB015013 for ; Wed, 10 Dec 2008 09:08:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBAH8b7t027739 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 10 Dec 2008 09:08:38 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBO00I0D7MC9N00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 10 Dec 2008 09:08:36 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO00DN47MADL70@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 10 Dec 2008 09:08:34 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBAH5L2Q004912 for ; Wed, 10 Dec 2008 17:08:34 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-408273 for LSARC-ext@sun.com; Wed, 10 Dec 2008 17:08:34 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-18168807 for LSARC-ext@sun.com; Wed, 10 Dec 2008 17:08:34 +0000 (Z) Received: from mail-ew0-f20.google.com ([209.85.219.20] [209.85.219.20]) by relay1ib.sun.com with ESMTP id BT-MMP-453181 for LSARC-ext@sun.com; Wed, 10 Dec 2008 17:08:33 +0000 (Z) Received: by ewy13 with SMTP id 13so879695ewy.8 for ; Wed, 10 Dec 2008 09:08:24 -0800 (PST) Received: by 10.210.61.8 with SMTP id j8mr1912684eba.45.1228928882549; Wed, 10 Dec 2008 09:08:02 -0800 (PST) Received: from ?172.16.12.121? ([70.232.181.5]) by mx.google.com with ESMTPS id 7sm309650eyg.52.2008.12.10.09.07.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Dec 2008 09:08:01 -0800 (PST) Date: Wed, 10 Dec 2008 11:07:57 -0600 From: Mark Martin Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: To: John Plocher Cc: Tom Childers , Dean Roehrich , Brian Utterback , Petr Slechta , LSARC-ext@sun.com Message-id: <493FF76D.9080304@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yLnc04bYahX8V4sYbXoB0i694JlO3l4qMXD5u+PHDcM=; b=vVMpCujux9P68P1cFUlsPQ35954tfK/P9aj/OIFNpckqEqZYs7hAPOdlvp0b/haeYp vdLdv2kBt8SwS25pLgmqyTr6ZTWpytCPhptHZ4lIJ5+lrUwNso+ZXSNy7si+9mdgVvMJ UkpyPx/J+zsKziH1PdiWGFp+D/f4lvwUuS3vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VCzIy/3Xeyz1VNYrInohMiaf4sdASfh7tomDSlUIf67ITZK5HKKBCYqeLb/bYYrfXu YMx2e+vxq3+1AMgk0MJeO4kLG23RrJ75Z1QJXI1P98mUpnhIr546AhB9yBD6e7649ref ZEGXSwsasE/yCBWmMwY3p8KMSLgVm6IScScOo= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.060sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810201939.m9KJdarc004982@sac.sfbay.sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 1582 John Plocher wrote: > On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers wrote: > >> ... then links may get changed and cause things to break. >> > > >> We asked the team to adopt the convention established for junit, LSARC/ >> 2008/633, similar to /usr/lib: >> >> /usr/share/lib/java/junit.jar link to most recent version >> /usr/share/lib/java/junit-4.5.jar >> /usr/share/lib/java/junit-3.8.2.jar >> ...etc. >> >> However, if they place all the findbugs pieces, like >> annotations-1.3.4.jar, in /usr/share/lib/java, then we have the >> situation that multiple projects who require and deliver the same >> component can overwrite each other. annotations.jar could be changed >> to link to a different version, breaking the functionality of >> something that is already installed. >> > > > Shouldn't those depend directly on the versioned item and > NOT on the convenience link? That is, if I depend on junit, I should either > > A) link to /usr/share/lib/java/junit.jar IFF the interface stability > I care about > is Committed, > or > B) link to /usr/share/lib/java/junit-4.5.jar if the interface > stability is less stable > Is there case precedent that indicates that all libraries should be versioned when installed? What happens for consumers of various version of: dom4j.jar, jaxen.jar, jsr-305.jar, et al listed there - presumably those won't be symlinks? Given the amount of java applications and scaffolding that's in the project pipeline, are we heading towards java jar hell? From tom.childers@sun.com Mon Dec 15 09:24:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBFHOuJE028012 for ; Mon, 15 Dec 2008 09:24:56 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBFHOlZe022350 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 16 Dec 2008 01:24:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBX00M13HPHMH00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 09:24:53 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBX00JZNHPG4140@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 09:24:52 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBFHOqjY010034 for ; Mon, 15 Dec 2008 09:24:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBX00F01H521B00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 09:24:52 -0800 (PST) Received: from [10.0.1.5] ([98.210.99.213]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBX009CVHP8F380@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 09:24:45 -0800 (PST) Date: Mon, 15 Dec 2008 09:24:40 -0800 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> Sender: Thomas.Childers@sun.com To: Petr Slechta Cc: LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> Status: RO Content-Length: 1193 Hello, Petr. Is that an acceptable solution? -tdc On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote: > On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: > >> Looking at this case, which has been sitting for a couple of weeks, I >> realize that Petr has raised an issue that we need to clarify. If >> we use >> links in /usr/share/java to point to the most recent version of each >> component, and underlying components can be delivered by different >> packages, then links may get changed and cause things to break. >> >> Can we simply assume that IPS handles this situation correctly? >> If so, are we requiring that all of these FOSS projects going into >> OpenSolaris use IPS? > > Those links need each to be delivered exactly once on a system, by > just one > package. No packaging system can deal with a single file being > delivered > multiple times by conflicting package developers. > > I'd suggest that projects either directly use the versioned jar file > that's > most appropriate for their needs, or install a symlink in a private > directory to the jar file they need, and put that in their classpath. > Perhaps there are other alternatives, too. > > Danek From James.Walker@sun.com Mon Dec 15 10:15:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBFIFwcp000018 for ; Mon, 15 Dec 2008 10:15:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBFIFpen061772 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 15 Dec 2008 11:15:58 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBX0021FK2LTS00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 10:15:57 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBX00JP0K2H3Q90@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 10:15:53 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBFIFqXL012138 for ; Mon, 15 Dec 2008 18:15:52 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBX00E01GYACK00@mail-amer.sun.com> (original mail from James.Walker@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 11:15:52 -0700 (MST) Received: from jim-walkers-macbook-pro.local ([129.150.37.151]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBX00NZDK2232E0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 15 Dec 2008 11:15:39 -0700 (MST) Date: Mon, 15 Dec 2008 11:15:37 -0700 From: Jim Walker Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: Sender: James.Walker@sun.com To: Petr Slechta Cc: Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Reply-to: James.Walker@sun.com Message-id: <49469EC9.8010801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) Status: RO Content-Length: 1605 Tom Childers wrote: > Hello, Petr. > > Is that an acceptable solution? -tdc > > On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote: > >> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: >> >>> Looking at this case, which has been sitting for a couple of >>> weeks, I realize that Petr has raised an issue that we need to >>> clarify. If we use links in /usr/share/java to point to the most >>> recent version of each component, and underlying components can >>> be delivered by different packages, then links may get changed >>> and cause things to break. >>> >>> Can we simply assume that IPS handles this situation correctly? >>> If so, are we requiring that all of these FOSS projects going >>> into OpenSolaris use IPS? >> >> Those links need each to be delivered exactly once on a system, by >> just one package. No packaging system can deal with a single file >> being delivered multiple times by conflicting package developers. >> >> I'd suggest that projects either directly use the versioned jar >> file that's most appropriate for their needs, or install a symlink >> in a private directory to the jar file they need, and put that in >> their classpath. Perhaps there are other alternatives, too. >> >> Danek > Right. The versioned jar files should be stable, only the junit.jar sym link will change over time. /usr/share/lib/java/junit.jar link to most recent version /usr/share/lib/java/junit-4.5.jar /usr/share/lib/java/junit-3.8.2.jar Mengwei plans to integrate junit-4.5 soon (c-team review is tomorrow). Petr, Does findbugs work with junit-4.5? Cheers, Jim From Petr.Slechta@sun.com Tue Dec 16 01:02:48 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBG92ljX000715 for ; Tue, 16 Dec 2008 01:02:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBG92ktn008033 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 16 Dec 2008 01:02:47 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBY00K1LP4MXW00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 02:02:46 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBY00C8YP4L3XF0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 02:02:45 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBG92iPs014048 for ; Tue, 16 Dec 2008 09:02:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBY00E01NNQ5400@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 09:02:44 +0000 (GMT) Received: from [10.162.49.184] ([85.160.13.192]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBY002EQP49MR10@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 09:02:39 +0000 (GMT) Date: Tue, 16 Dec 2008 10:02:32 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49469EC9.8010801@sun.com> Sender: Petr.Slechta@sun.com To: James.Walker@sun.com Cc: Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <49476EA8.1060703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 1887 Jim Walker wrote: > Tom Childers wrote: >> Hello, Petr. >> >> Is that an acceptable solution? -tdc >> >> On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote: >> >>> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: >>> >>>> Looking at this case, which has been sitting for a couple of >>>> weeks, I realize that Petr has raised an issue that we need to >>>> clarify. If we use links in /usr/share/java to point to the most >>>> recent version of each component, and underlying components can >>>> be delivered by different packages, then links may get changed >>>> and cause things to break. >>>> >>>> Can we simply assume that IPS handles this situation correctly? If >>>> so, are we requiring that all of these FOSS projects going >>>> into OpenSolaris use IPS? >>> >>> Those links need each to be delivered exactly once on a system, by >>> just one package. No packaging system can deal with a single file >>> being delivered multiple times by conflicting package developers. >>> >>> I'd suggest that projects either directly use the versioned jar >>> file that's most appropriate for their needs, or install a symlink >>> in a private directory to the jar file they need, and put that in >>> their classpath. Perhaps there are other alternatives, too. >>> >>> Danek >> > > Right. The versioned jar files should be stable, only the junit.jar > sym link will change over time. > > /usr/share/lib/java/junit.jar link to most recent version > /usr/share/lib/java/junit-4.5.jar > /usr/share/lib/java/junit-3.8.2.jar > > Mengwei plans to integrate junit-4.5 soon (c-team review is tomorrow). > > Petr, > > Does findbugs work with junit-4.5? > > Cheers, > Jim JUnit is used only during build. We will skip some of the tests, because they are targeted for Eclipse integration, etc. I did not try to run compilation of findbugs with different JUnit, but I will do it. Petr From Petr.Slechta@sun.com Tue Dec 16 10:36:58 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBGIawFH015889 for ; Tue, 16 Dec 2008 10:36:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBGIat88026326 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 16 Dec 2008 10:36:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBZ0010VFPL9U00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 10:36:57 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBZ00HZPFPKCZE0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 10:36:57 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBGIauJL015482 for ; Tue, 16 Dec 2008 18:36:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBZ00I01FO8HQ00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 18:36:56 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBZ000LPFPJL1E0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 18:36:56 +0000 (GMT) Date: Tue, 16 Dec 2008 19:36:53 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49469EC9.8010801@sun.com> Sender: Petr.Slechta@sun.com To: James.Walker@sun.com Cc: Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <4947F545.8020704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 4376 Dear LSARC reviewers, please confirm, that the following structure of findbugs package is OK: /usr/bin/*findbugs* /usr/share/doc/*findbugs* /usr/share/doc/*findbugs*/LICENSE.txt /usr/share/doc/*findbugs*/README.txt /usr/share/doc/*findbugs*/ /usr/share/doc/*findbugs*/manual/ /usr/share/*findbugs* /usr/share/*findbugs*/bin /usr/share/*findbugs*/bin/addMessages /usr/share/*findbugs*/bin/computeBugHistory /usr/share/*findbugs*/bin/convertXmlToText /usr/share/*findbugs*/bin/copyBuggySource /usr/share/*findbugs*/bin/defectDensity /usr/share/*findbugs*/bin/deprecated /usr/share/*findbugs*/bin/deprecated/bugHistory /usr/share/*findbugs*/bin/deprecated/unionBugs /usr/share/*findbugs*/bin/deprecated/unionResults /usr/share/*findbugs*/bin/deprecated/updateBugs /usr/share/*findbugs*/bin/fbwrap /usr/share/*findbugs*/bin/filterBugs /usr/share/*findbugs*/bin/*findbugs* /usr/share/*findbugs*/bin/*findbugs2* /usr/share/*findbugs*/bin/listBugDatabaseInfo /usr/share/*findbugs*/bin/mineBugHistory /usr/share/*findbugs*/bin/printAppVersion /usr/share/*findbugs*/bin/printClass /usr/share/*findbugs*/bin/rejarForAnalysis /usr/share/*findbugs*/bin/setBugDatabaseInfo /usr/share/*findbugs*/bin/unionBugs /usr/share/*findbugs*/bin/xpathFind /usr/share/lib/java/*findbugs* /usr/share/lib/java/*findbugs*/lib /usr/share/lib/java/*findbugs*/lib/annotations-1.3.4.jar /usr/share/lib/java/*findbugs*/lib/asm-3.1.jar /usr/share/lib/java/*findbugs*/lib/asm-analysis-3.1.jar /usr/share/lib/java/*findbugs*/lib/asm-commons-3.1.jar /usr/share/lib/java/*findbugs*/lib/asm-tree-3.1.jar /usr/share/lib/java/*findbugs*/lib/asm-util-3.1.jar /usr/share/lib/java/*findbugs*/lib/asm-xml-3.1.jar /usr/share/lib/java/*findbugs*/lib/bcel-5.3.jar /usr/share/lib/java/*findbugs*/lib/dom4j-1.6.1.jar /usr/share/lib/java/*findbugs*/lib/*findbugs*-1.3.4.jar /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant-1.3.4.jar /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant.jar -> *findbugs*-ant-1.3.4.jar /usr/share/lib/java/*findbugs*/lib/*findbugs*.jar -> *findbugs*-1.3.4.jar /usr/share/lib/java/*findbugs*/lib/jaxen-1.1.1.jar /usr/share/lib/java/*findbugs*/lib/jsr-305.jar You can see that all jar libraries have version number, so there should be no clashes. The only exception is jsr-305.jar, where I'm not sure if it has any version number... Can you advice? Or should I assign any artificial number (like 1.0)? Also please see two links (finbugs.jar, and findbugs-ant.jar that point to the latest version of finbugs (if any external application wants to use findbugs)... Please let me know if the package structure is OK. What else should I do to finish this LSARC review? Thanks, Petr Jim Walker wrote: > Tom Childers wrote: >> Hello, Petr. >> >> Is that an acceptable solution? -tdc >> >> On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote: >> >>> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: >>> >>>> Looking at this case, which has been sitting for a couple of >>>> weeks, I realize that Petr has raised an issue that we need to >>>> clarify. If we use links in /usr/share/java to point to the most >>>> recent version of each component, and underlying components can >>>> be delivered by different packages, then links may get changed >>>> and cause things to break. >>>> >>>> Can we simply assume that IPS handles this situation correctly? If >>>> so, are we requiring that all of these FOSS projects going >>>> into OpenSolaris use IPS? >>> >>> Those links need each to be delivered exactly once on a system, by >>> just one package. No packaging system can deal with a single file >>> being delivered multiple times by conflicting package developers. >>> >>> I'd suggest that projects either directly use the versioned jar >>> file that's most appropriate for their needs, or install a symlink >>> in a private directory to the jar file they need, and put that in >>> their classpath. Perhaps there are other alternatives, too. >>> >>> Danek >> > > Right. The versioned jar files should be stable, only the junit.jar > sym link will change over time. > > /usr/share/lib/java/junit.jar link to most recent version > /usr/share/lib/java/junit-4.5.jar > /usr/share/lib/java/junit-3.8.2.jar > > Mengwei plans to integrate junit-4.5 soon (c-team review is tomorrow). > > Petr, > > Does findbugs work with junit-4.5? > > Cheers, > Jim From Petr.Slechta@sun.com Tue Dec 16 10:40:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBGIe4rJ016125 for ; Tue, 16 Dec 2008 10:40:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBGIe0sC028157 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 16 Dec 2008 10:40:04 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBZ0071BFUQOY00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 11:40:02 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBZ00L5SFUP5D80@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 11:40:01 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBGIe0u9014750 for ; Tue, 16 Dec 2008 18:40:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBZ00J01FRLWR00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 18:40:00 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBZ000L7FUIL1F0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 18:39:54 +0000 (GMT) Date: Tue, 16 Dec 2008 19:39:52 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] (correction) In-reply-to: <4947F545.8020704@sun.com> Sender: Petr.Slechta@sun.com To: James.Walker@sun.com Cc: Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <4947F5F8.3090409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <082626B8-124C-46F7-B79E-E0FEBE2306BD@sun.com> <48FE460B.1040204@sun.com> <53B87ED4-B329-4062-9842-A8FFAD2EA1DE@sun.com> <49060D8C.8090807@sun.com> <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 4526 Correcting the extra star characters in paths... Petr Petr Slechta wrote: > Dear LSARC reviewers, > > please confirm, that the following structure of findbugs package is OK: > > /usr/bin/findbugs > /usr/share/doc/findbugs > /usr/share/doc/findbugs/LICENSE.txt > /usr/share/doc/findbugs/README.txt > /usr/share/doc/findbugs/ > /usr/share/doc/findbugs/manual/ > /usr/share/findbugs > /usr/share/findbugs/bin > /usr/share/findbugs/bin/addMessages > /usr/share/findbugs/bin/computeBugHistory > /usr/share/findbugs/bin/convertXmlToText > /usr/share/findbugs/bin/copyBuggySource > /usr/share/findbugs/bin/defectDensity > /usr/share/findbugs/bin/deprecated > /usr/share/findbugs/bin/deprecated/bugHistory > /usr/share/findbugs/bin/deprecated/unionBugs > /usr/share/findbugs/bin/deprecated/unionResults > /usr/share/findbugs/bin/deprecated/updateBugs > /usr/share/findbugs/bin/fbwrap > /usr/share/findbugs/bin/filterBugs > /usr/share/findbugs/bin/findbugs > /usr/share/findbugs/bin/findbugs2 > /usr/share/findbugs/bin/listBugDatabaseInfo > /usr/share/findbugs/bin/mineBugHistory > /usr/share/findbugs/bin/printAppVersion > /usr/share/findbugs/bin/printClass > /usr/share/findbugs/bin/rejarForAnalysis > /usr/share/findbugs/bin/setBugDatabaseInfo > /usr/share/findbugs/bin/unionBugs > /usr/share/findbugs/bin/xpathFind > /usr/share/lib/java/findbugs > /usr/share/lib/java/findbugs/lib > /usr/share/lib/java/findbugs/lib/annotations-1.3.4.jar > /usr/share/lib/java/findbugs/lib/asm-3.1.jar > /usr/share/lib/java/findbugs/lib/asm-analysis-3.1.jar > /usr/share/lib/java/findbugs/lib/asm-commons-3.1.jar > /usr/share/lib/java/findbugs/lib/asm-tree-3.1.jar > /usr/share/lib/java/findbugs/lib/asm-util-3.1.jar > /usr/share/lib/java/findbugs/lib/asm-xml-3.1.jar > /usr/share/lib/java/findbugs/lib/bcel-5.3.jar > /usr/share/lib/java/findbugs/lib/dom4j-1.6.1.jar > /usr/share/lib/java/findbugs/lib/findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/lib/findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs/lib/findbugs-ant.jar -> > findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs/lib/findbugs.jar -> findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/lib/jaxen-1.1.1.jar > /usr/share/lib/java/findbugs/lib/jsr-305.jar > > You can see that all jar libraries have version number, so there > should be no clashes. The only exception is jsr-305.jar, where I'm not > sure if it has any version number... Can you advice? Or should I > assign any artificial number (like 1.0)? > > Also please see two links (finbugs.jar, and findbugs-ant.jar that > point to the latest version of finbugs (if any external application > wants to use findbugs)... > > Please let me know if the package structure is OK. What else should I > do to finish this LSARC review? > > Thanks, > > Petr > > > Jim Walker wrote: >> Tom Childers wrote: >>> Hello, Petr. >>> >>> Is that an acceptable solution? -tdc >>> >>> On Dec 9, 2008, at 11:14 AM, Danek Duvall wrote: >>> >>>> On Tue, Dec 09, 2008 at 11:01:31AM -0800, Tom Childers wrote: >>>> >>>>> Looking at this case, which has been sitting for a couple of >>>>> weeks, I realize that Petr has raised an issue that we need to >>>>> clarify. If we use links in /usr/share/java to point to the most >>>>> recent version of each component, and underlying components can >>>>> be delivered by different packages, then links may get changed >>>>> and cause things to break. >>>>> >>>>> Can we simply assume that IPS handles this situation correctly? If >>>>> so, are we requiring that all of these FOSS projects going >>>>> into OpenSolaris use IPS? >>>> >>>> Those links need each to be delivered exactly once on a system, by >>>> just one package. No packaging system can deal with a single file >>>> being delivered multiple times by conflicting package developers. >>>> >>>> I'd suggest that projects either directly use the versioned jar >>>> file that's most appropriate for their needs, or install a symlink >>>> in a private directory to the jar file they need, and put that in >>>> their classpath. Perhaps there are other alternatives, too. >>>> >>>> Danek >>> >> >> Right. The versioned jar files should be stable, only the junit.jar >> sym link will change over time. >> >> /usr/share/lib/java/junit.jar link to most recent version >> /usr/share/lib/java/junit-4.5.jar >> /usr/share/lib/java/junit-3.8.2.jar >> >> Mengwei plans to integrate junit-4.5 soon (c-team review is tomorrow). >> >> Petr, >> >> Does findbugs work with junit-4.5? >> >> Cheers, >> Jim > > From danek.duvall@sun.com Tue Dec 16 10:45:30 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBGIjUjt016372 for ; Tue, 16 Dec 2008 10:45:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBGIjSIU029263; Tue, 16 Dec 2008 10:45:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBZ0010HG3TRS00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Dec 2008 10:45:29 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBZ001Z7G3SBF40@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Dec 2008 10:45:29 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBGIjQY4004646; Tue, 16 Dec 2008 10:45:26 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBGIl1wR007393; Tue, 16 Dec 2008 10:47:01 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBGIl1jO007392; Tue, 16 Dec 2008 10:47:01 -0800 (PST) Date: Tue, 16 Dec 2008 10:47:01 -0800 From: Danek Duvall Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4947F545.8020704@sun.com> To: Petr Slechta Cc: James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <20081216184701.GX7263@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2418 On Tue, Dec 16, 2008 at 07:36:53PM +0100, Petr Slechta wrote: > please confirm, that the following structure of findbugs package is OK: I assume that there aren't actually any asterisks in the pathnames ... > /usr/share/lib/java/*findbugs*/lib/annotations-1.3.4.jar > /usr/share/lib/java/*findbugs*/lib/asm-3.1.jar > /usr/share/lib/java/*findbugs*/lib/asm-analysis-3.1.jar > /usr/share/lib/java/*findbugs*/lib/asm-commons-3.1.jar > /usr/share/lib/java/*findbugs*/lib/asm-tree-3.1.jar > /usr/share/lib/java/*findbugs*/lib/asm-util-3.1.jar > /usr/share/lib/java/*findbugs*/lib/asm-xml-3.1.jar > /usr/share/lib/java/*findbugs*/lib/bcel-5.3.jar > /usr/share/lib/java/*findbugs*/lib/dom4j-1.6.1.jar > /usr/share/lib/java/*findbugs*/lib/*findbugs*-1.3.4.jar > /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant-1.3.4.jar > /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant.jar -> *findbugs*-ant-1.3.4.jar > /usr/share/lib/java/*findbugs*/lib/*findbugs*.jar -> *findbugs*-1.3.4.jar > /usr/share/lib/java/*findbugs*/lib/jaxen-1.1.1.jar > /usr/share/lib/java/*findbugs*/lib/jsr-305.jar > > You can see that all jar libraries have version number, so there should be > no clashes. The only exception is jsr-305.jar, where I'm not sure if it has > any version number... Can you advice? Or should I assign any artificial > number (like 1.0)? Given that these libraries are all in what I would expect is a Project Private directory (/usr/share/lib/java/findbugs), you can name these jar files whatever you please since no other project will be able to depend on their names and thus break if the names change. I wouldn't assign any version numbers to something that doesn't have it. And, in general, I wouldn't reference the versioned jar files in scripts since that means every time you upgrade a jar file, you have to upgrade the script, which is extra work, and can lead to its own set of issues. You also don't really need the lower "lib" directory. But that's only personal advice -- like I said, you can do whatever you like in a private space. > Also please see two links (finbugs.jar, and findbugs-ant.jar that point to > the latest version of finbugs (if any external application wants to use > findbugs)... If these aren't Private, they should be less buried than the rest of the jar files. Either the rest need to be put in a deeper directory, or these two need to be raised up a couple of levels. Danek From Petr.Slechta@sun.com Tue Dec 16 10:53:24 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBGIrNVc016689 for ; Tue, 16 Dec 2008 10:53:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBGIqnJ6016827 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 17 Dec 2008 02:53:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBZ00B0RGGT9100@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 10:53:17 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBZ002WBGGSLH70@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 10:53:16 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBGIrFPC016318 for ; Tue, 16 Dec 2008 18:53:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBZ00501GFI5L00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 16 Dec 2008 18:53:15 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBZ001L4GGQSW90@fe-emea-10.sun.com>; Tue, 16 Dec 2008 18:53:15 +0000 (GMT) Date: Tue, 16 Dec 2008 19:53:13 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081216184701.GX7263@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@sun.com To: Danek Duvall Cc: James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <4947F919.3030001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4908A338.8030108@sun.com> <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 4657 Please see the new version of package structure: /usr/bin/findbugs /usr/share/doc/findbugs /usr/share/doc/findbugs/LICENSE.txt /usr/share/doc/findbugs/README.txt /usr/share/doc/findbugs/ /usr/share/doc/findbugs/manual/ /usr/share/findbugs /usr/share/findbugs/bin /usr/share/findbugs/bin/addMessages /usr/share/findbugs/bin/computeBugHistory /usr/share/findbugs/bin/convertXmlToText /usr/share/findbugs/bin/copyBuggySource /usr/share/findbugs/bin/defectDensity /usr/share/findbugs/bin/deprecated /usr/share/findbugs/bin/deprecated/bugHistory /usr/share/findbugs/bin/deprecated/unionBugs /usr/share/findbugs/bin/deprecated/unionResults /usr/share/findbugs/bin/deprecated/updateBugs /usr/share/findbugs/bin/fbwrap /usr/share/findbugs/bin/filterBugs /usr/share/findbugs/bin/findbugs /usr/share/findbugs/bin/findbugs2 /usr/share/findbugs/bin/listBugDatabaseInfo /usr/share/findbugs/bin/mineBugHistory /usr/share/findbugs/bin/printAppVersion /usr/share/findbugs/bin/printClass /usr/share/findbugs/bin/rejarForAnalysis /usr/share/findbugs/bin/setBugDatabaseInfo /usr/share/findbugs/bin/unionBugs /usr/share/findbugs/bin/xpathFind /usr/share/lib/java/findbugs /usr/share/lib/java/findbugs/annotations-1.3.4.jar /usr/share/lib/java/findbugs/asm-3.1.jar /usr/share/lib/java/findbugs/asm-analysis-3.1.jar /usr/share/lib/java/findbugs/asm-commons-3.1.jar /usr/share/lib/java/findbugs/asm-tree-3.1.jar /usr/share/lib/java/findbugs/asm-util-3.1.jar /usr/share/lib/java/findbugs/asm-xml-3.1.jar /usr/share/lib/java/findbugs/bcel-5.3.jar /usr/share/lib/java/findbugs/dom4j-1.6.1.jar /usr/share/lib/java/findbugs/findbugs-1.3.4.jar /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar /usr/share/lib/java/findbugs/jaxen-1.1.1.jar /usr/share/lib/java/findbugs/jsr-305.jar Is it OK this way? Thanks! Petr Danek Duvall wrote: > On Tue, Dec 16, 2008 at 07:36:53PM +0100, Petr Slechta wrote: > > >> please confirm, that the following structure of findbugs package is OK: >> > > I assume that there aren't actually any asterisks in the pathnames ... > Yes, I already sent corrected version without asterisks. > >> /usr/share/lib/java/*findbugs*/lib/annotations-1.3.4.jar >> /usr/share/lib/java/*findbugs*/lib/asm-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/asm-analysis-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/asm-commons-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/asm-tree-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/asm-util-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/asm-xml-3.1.jar >> /usr/share/lib/java/*findbugs*/lib/bcel-5.3.jar >> /usr/share/lib/java/*findbugs*/lib/dom4j-1.6.1.jar >> /usr/share/lib/java/*findbugs*/lib/*findbugs*-1.3.4.jar >> /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant-1.3.4.jar >> /usr/share/lib/java/*findbugs*/lib/*findbugs*-ant.jar -> *findbugs*-ant-1.3.4.jar >> /usr/share/lib/java/*findbugs*/lib/*findbugs*.jar -> *findbugs*-1.3.4.jar >> /usr/share/lib/java/*findbugs*/lib/jaxen-1.1.1.jar >> /usr/share/lib/java/*findbugs*/lib/jsr-305.jar >> >> You can see that all jar libraries have version number, so there should be >> no clashes. The only exception is jsr-305.jar, where I'm not sure if it has >> any version number... Can you advice? Or should I assign any artificial >> number (like 1.0)? >> > > Given that these libraries are all in what I would expect is a Project > Private directory (/usr/share/lib/java/findbugs), you can name these jar > files whatever you please since no other project will be able to depend on > their names and thus break if the names change. > > I wouldn't assign any version numbers to something that doesn't have it. > And, in general, I wouldn't reference the versioned jar files in scripts > since that means every time you upgrade a jar file, you have to upgrade the > script, which is extra work, and can lead to its own set of issues. You > also don't really need the lower "lib" directory. But that's only personal > advice -- like I said, you can do whatever you like in a private space. > > OK. I will put them into private space. >> Also please see two links (finbugs.jar, and findbugs-ant.jar that point to >> the latest version of finbugs (if any external application wants to use >> findbugs)... >> > > If these aren't Private, they should be less buried than the rest of the > jar files. Either the rest need to be put in a deeper directory, or these > two need to be raised up a couple of levels. > Please see new version of package structure. > Danek > From danek.duvall@sun.com Tue Dec 16 10:56:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBGIuM3A017297 for ; Tue, 16 Dec 2008 10:56:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBGInNkH004295; Tue, 16 Dec 2008 10:56:21 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBZ00201GLUCK00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Dec 2008 10:56:18 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBZ0013IGLSBFB0@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Dec 2008 10:56:17 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBGIuF5S013072; Tue, 16 Dec 2008 10:56:15 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBGIvojA007680; Tue, 16 Dec 2008 10:57:50 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBGIvoD0007679; Tue, 16 Dec 2008 10:57:50 -0800 (PST) Date: Tue, 16 Dec 2008 10:57:50 -0800 From: Danek Duvall Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4947F919.3030001@sun.com> To: Petr Slechta Cc: James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <20081216185750.GY7263@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 510 On Tue, Dec 16, 2008 at 07:53:13PM +0100, Petr Slechta wrote: > [ ... ] > /usr/share/lib/java/findbugs/dom4j-1.6.1.jar > /usr/share/lib/java/findbugs/findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/jaxen-1.1.1.jar > /usr/share/lib/java/findbugs/jsr-305.jar > > Is it OK this way? This looks fine to me. Danek From Petr.Slechta@sun.com Wed Dec 17 03:09:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHB9gZQ009659 for ; Wed, 17 Dec 2008 03:09:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHB9S6t017901 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 17 Dec 2008 11:09:41 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC000DCHPO4GC00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 04:09:40 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC000MBKPO06RB0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 04:09:37 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBHB9aO6012266 for ; Wed, 17 Dec 2008 11:09:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC000701OJ6L000@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 11:09:36 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC0002DKPNZQ730@fe-emea-10.sun.com>; Wed, 17 Dec 2008 11:09:35 +0000 (GMT) Date: Wed, 17 Dec 2008 12:09:33 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081216185750.GY7263@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@sun.com To: Danek Duvall Cc: James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <4948DDED.8080309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 4020 Hello LSARC reviewers! I need to close this LSARC case (we have agreement on package structure). I suppose that foss checklist needs to be updated: http://sac.eng.sun.com/Archives/CaseLog/arc/LSARC/2008/642/fosslist.txt The new version of section 4.0 is below: 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments ----------------------------- ------------------- --------------------------- SUNWfindbugs committed package name /usr/bin/findbugs uncommitted command /usr/share/doc/findbugs uncommitted documentation and license /usr/share/findbugs/bin uncommitted additional findbugs' commands /usr/share/lib/java/findbugs uncommitted findbugs' private libraries /usr/share/lib/java/findbugs.jar uncommitted findbugs' exported library /usr/share/lib/java/findbugs-ant.jar uncommitted findbugs' exported library 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- JAVA_HOME committed environment variable (widely used) FindBugs require Java 1.5 or later. Is this section OK this way? Just FYI, the whole package structure is the following: /usr/bin/findbugs /usr/share/doc/findbugs /usr/share/doc/findbugs/LICENSE.txt /usr/share/doc/findbugs/README.txt /usr/share/doc/findbugs/ /usr/share/doc/findbugs/manual/ /usr/share/findbugs /usr/share/findbugs/bin /usr/share/findbugs/bin/addMessages /usr/share/findbugs/bin/computeBugHistory /usr/share/findbugs/bin/convertXmlToText /usr/share/findbugs/bin/copyBuggySource /usr/share/findbugs/bin/defectDensity /usr/share/findbugs/bin/deprecated /usr/share/findbugs/bin/deprecated/bugHistory /usr/share/findbugs/bin/deprecated/unionBugs /usr/share/findbugs/bin/deprecated/unionResults /usr/share/findbugs/bin/deprecated/updateBugs /usr/share/findbugs/bin/fbwrap /usr/share/findbugs/bin/filterBugs /usr/share/findbugs/bin/findbugs /usr/share/findbugs/bin/findbugs2 /usr/share/findbugs/bin/listBugDatabaseInfo /usr/share/findbugs/bin/mineBugHistory /usr/share/findbugs/bin/printAppVersion /usr/share/findbugs/bin/printClass /usr/share/findbugs/bin/rejarForAnalysis /usr/share/findbugs/bin/setBugDatabaseInfo /usr/share/findbugs/bin/unionBugs /usr/share/findbugs/bin/xpathFind /usr/share/lib/java/findbugs /usr/share/lib/java/findbugs/annotations-1.3.4.jar /usr/share/lib/java/findbugs/asm-3.1.jar /usr/share/lib/java/findbugs/asm-analysis-3.1.jar /usr/share/lib/java/findbugs/asm-commons-3.1.jar /usr/share/lib/java/findbugs/asm-tree-3.1.jar /usr/share/lib/java/findbugs/asm-util-3.1.jar /usr/share/lib/java/findbugs/asm-xml-3.1.jar /usr/share/lib/java/findbugs/bcel-5.3.jar /usr/share/lib/java/findbugs/dom4j-1.6.1.jar /usr/share/lib/java/findbugs/findbugs-1.3.4.jar /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar /usr/share/lib/java/findbugs/jaxen-1.1.1.jar /usr/share/lib/java/findbugs/jsr-305.jar Could we consider this LSARC case as approved? If not, please let me know what else should be done. Thanks! Petr Danek Duvall wrote: > On Tue, Dec 16, 2008 at 07:53:13PM +0100, Petr Slechta wrote: > > >> [ ... ] >> /usr/share/lib/java/findbugs/dom4j-1.6.1.jar >> /usr/share/lib/java/findbugs/findbugs-1.3.4.jar >> /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar >> /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar >> /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar >> /usr/share/lib/java/findbugs/jaxen-1.1.1.jar >> /usr/share/lib/java/findbugs/jsr-305.jar >> >> Is it OK this way? >> > > This looks fine to me. > > Danek > From brian.utterback@Sun.com Wed Dec 17 05:46:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHDkmdW028025 for ; Wed, 17 Dec 2008 05:46:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHDkQK6028685; Wed, 17 Dec 2008 13:46:46 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC00040BWXX9I00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 05:46:45 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC0003N5WXWA130@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 05:46:45 -0800 (PST) Received: from [129.148.9.37] (sr1-ubur-13.East.Sun.COM [129.148.9.37]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHDkebb034995; Wed, 17 Dec 2008 08:46:41 -0500 (EST) Date: Wed, 17 Dec 2008 08:46:40 -0500 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4948DDED.8080309@sun.com> To: Petr Slechta Cc: Danek Duvall , James.Walker@Sun.com, Tom Childers , LSARC-ext@Sun.com, Dean Roehrich Message-id: <494902C0.7040905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490EC960.8080205@sun.com> <04D1B493-BFA5-4516-B648-86CCC45520C9@sun.com> <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> User-Agent: Thunderbird 2.0.0.19pre (X11/20081201) Status: RO Content-Length: 5094 I have update the case directory with the changes to the foss checklist. I have reset the timer to this Friday, since the only issue was where to install the files and what to name them, which now is resolved. I think til Friday should give everyone a chance to review the changes. If any one disagrees, please let me know. Petr Slechta wrote: > Hello LSARC reviewers! > > I need to close this LSARC case (we have agreement on package structure). > > I suppose that foss checklist needs to be updated: > http://sac.eng.sun.com/Archives/CaseLog/arc/LSARC/2008/642/fosslist.txt > > The new version of section 4.0 is below: > > 4.0 Interfaces > (see > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ > for details) > 4.1 Exported Interfaces > > Interface Name Classification Comments > ----------------------------- ------------------- > --------------------------- > SUNWfindbugs committed package name > > /usr/bin/findbugs uncommitted command > /usr/share/doc/findbugs uncommitted documentation and > license > /usr/share/findbugs/bin uncommitted additional > findbugs' commands > /usr/share/lib/java/findbugs uncommitted findbugs' private > libraries > /usr/share/lib/java/findbugs.jar uncommitted findbugs' exported > library > /usr/share/lib/java/findbugs-ant.jar uncommitted findbugs' exported > library > > 4.2 Imported Interfaces > Interface Name Classification Comments > --------------------------- -------------------- > -------------------------- > JAVA_HOME committed environment variable > (widely used) > > FindBugs require Java 1.5 or later. > > Is this section OK this way? > > Just FYI, the whole package structure is the following: > > /usr/bin/findbugs > /usr/share/doc/findbugs > /usr/share/doc/findbugs/LICENSE.txt > /usr/share/doc/findbugs/README.txt > /usr/share/doc/findbugs/ > /usr/share/doc/findbugs/manual/ > /usr/share/findbugs > /usr/share/findbugs/bin > /usr/share/findbugs/bin/addMessages > /usr/share/findbugs/bin/computeBugHistory > /usr/share/findbugs/bin/convertXmlToText > /usr/share/findbugs/bin/copyBuggySource > /usr/share/findbugs/bin/defectDensity > /usr/share/findbugs/bin/deprecated > /usr/share/findbugs/bin/deprecated/bugHistory > /usr/share/findbugs/bin/deprecated/unionBugs > /usr/share/findbugs/bin/deprecated/unionResults > /usr/share/findbugs/bin/deprecated/updateBugs > /usr/share/findbugs/bin/fbwrap > /usr/share/findbugs/bin/filterBugs > /usr/share/findbugs/bin/findbugs > /usr/share/findbugs/bin/findbugs2 > /usr/share/findbugs/bin/listBugDatabaseInfo > /usr/share/findbugs/bin/mineBugHistory > /usr/share/findbugs/bin/printAppVersion > /usr/share/findbugs/bin/printClass > /usr/share/findbugs/bin/rejarForAnalysis > /usr/share/findbugs/bin/setBugDatabaseInfo > /usr/share/findbugs/bin/unionBugs > /usr/share/findbugs/bin/xpathFind > /usr/share/lib/java/findbugs > /usr/share/lib/java/findbugs/annotations-1.3.4.jar > /usr/share/lib/java/findbugs/asm-3.1.jar > /usr/share/lib/java/findbugs/asm-analysis-3.1.jar > /usr/share/lib/java/findbugs/asm-commons-3.1.jar > /usr/share/lib/java/findbugs/asm-tree-3.1.jar > /usr/share/lib/java/findbugs/asm-util-3.1.jar > /usr/share/lib/java/findbugs/asm-xml-3.1.jar > /usr/share/lib/java/findbugs/bcel-5.3.jar > /usr/share/lib/java/findbugs/dom4j-1.6.1.jar > /usr/share/lib/java/findbugs/findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar > /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar > /usr/share/lib/java/findbugs/jaxen-1.1.1.jar > /usr/share/lib/java/findbugs/jsr-305.jar > > > > Could we consider this LSARC case as approved? If not, please let me > know what else should be done. > > Thanks! > > Petr > > > Danek Duvall wrote: >> On Tue, Dec 16, 2008 at 07:53:13PM +0100, Petr Slechta wrote: >> >> >>> [ ... ] >>> /usr/share/lib/java/findbugs/dom4j-1.6.1.jar >>> /usr/share/lib/java/findbugs/findbugs-1.3.4.jar >>> /usr/share/lib/java/findbugs/findbugs-ant-1.3.4.jar >>> /usr/share/lib/java/findbugs-ant.jar -> findbugs/findbugs-ant-1.3.4.jar >>> /usr/share/lib/java/findbugs.jar -> findbugs/findbugs-1.3.4.jar >>> /usr/share/lib/java/findbugs/jaxen-1.1.1.jar >>> /usr/share/lib/java/findbugs/jsr-305.jar >>> >>> Is it OK this way? >>> >> >> This looks fine to me. >> >> Danek >> > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From danek.duvall@sun.com Wed Dec 17 06:13:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHEDtfV028553 for ; Wed, 17 Dec 2008 06:13:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBHEDZ3o020008; Wed, 17 Dec 2008 22:13:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC000503Y72PO00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 06:13:50 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC0003HLY71A190@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 06:13:49 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHEDiTW065207; Wed, 17 Dec 2008 06:13:47 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBHEFKUH012875; Wed, 17 Dec 2008 06:15:20 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBHEFK3n012874; Wed, 17 Dec 2008 06:15:20 -0800 (PST) Date: Wed, 17 Dec 2008 06:15:20 -0800 From: Danek Duvall Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4948DDED.8080309@sun.com> To: Petr Slechta Cc: James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Brian Utterback , Dean Roehrich Message-id: <20081217141520.GF25343@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 426 On Wed, Dec 17, 2008 at 12:09:33PM +0100, Petr Slechta wrote: > /usr/share/doc/findbugs uncommitted documentation and license Documentation isn't an interface, so this shouldn't be in the interface table. > /usr/share/lib/java/findbugs uncommitted findbugs' private libraries This is a Project Private interface, since no project but yours is allowed to use it. Otherwise, looks fine. Danek From brian.utterback@sun.com Wed Dec 17 07:18:58 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHFIwJV029484 for ; Wed, 17 Dec 2008 07:18:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBHFIvrD006855; Wed, 17 Dec 2008 07:18:57 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC100C0517JZX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Dec 2008 07:18:55 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC1007D517HVT90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Dec 2008 07:18:54 -0800 (PST) Received: from [129.148.9.37] (sr1-ubur-13.East.Sun.COM [129.148.9.37]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHFInWx016602; Wed, 17 Dec 2008 10:18:50 -0500 (EST) Date: Wed, 17 Dec 2008 10:18:49 -0500 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081217141520.GF25343@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Petr Slechta , James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Dean Roehrich Message-id: <49491859.5060407@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4923E210.6030803@sun.com> <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19pre (X11/20081201) Status: RO Content-Length: 1068 I think that this is documenting the location, rather than the contents of these directories. Danek Duvall wrote: > On Wed, Dec 17, 2008 at 12:09:33PM +0100, Petr Slechta wrote: > >> /usr/share/doc/findbugs uncommitted documentation and license > > Documentation isn't an interface, so this shouldn't be in the interface > table. > >> /usr/share/lib/java/findbugs uncommitted findbugs' private libraries > > This is a Project Private interface, since no project but yours is allowed > to use it. > > Otherwise, looks fine. > > Danek -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From danek.duvall@sun.com Wed Dec 17 08:13:12 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHGDCSr016640 for ; Wed, 17 Dec 2008 08:13:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBHGD2LC008742; Wed, 17 Dec 2008 08:13:11 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC100B1X3PXVW00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 08:13:09 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC1006I13PXWIE0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Dec 2008 08:13:09 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHGD7DP029185; Wed, 17 Dec 2008 08:13:07 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBHGEh9p013286; Wed, 17 Dec 2008 08:14:43 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBHGEhMP013285; Wed, 17 Dec 2008 08:14:43 -0800 (PST) Date: Wed, 17 Dec 2008 08:14:43 -0800 From: Danek Duvall Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49491859.5060407@sun.com> To: Brian Utterback Cc: Petr Slechta , James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Dean Roehrich Message-id: <20081217161443.GE7263@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> <49491859.5060407@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 675 On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote: > I think that this is documenting the location, rather than the contents of > these directories. Projects document exported (and imported) interfaces. Exported interfaces are exported because the project team expects them to be imported from other projects. If you'd like to explain in what sense these directories are intended to be used by other projects, please do. Otherwise, the documentation directory is Not an Interface, and the private directory full of jar files is Project Private. Simply filling a slot in a Public directory's namespace isn't sufficient to make an interface Public. Danek From Petr.Slechta@sun.com Wed Dec 17 08:21:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBHGLFKw016904 for ; Wed, 17 Dec 2008 08:21:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBHGL7bA028867 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 18 Dec 2008 00:21:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC100C1143CAB00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 08:21:12 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC100CJQ43B2W00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 08:21:11 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBHGLAfV011711 for ; Wed, 17 Dec 2008 16:21:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC100B013KTZQ00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 17 Dec 2008 16:21:10 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC100JU842GSYF0@fe-emea-10.sun.com>; Wed, 17 Dec 2008 16:20:41 +0000 (GMT) Date: Wed, 17 Dec 2008 17:20:38 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <20081217161443.GE7263@mumak.SFBay.Sun.COM> Sender: Petr.Slechta@sun.com To: Danek Duvall Cc: Brian Utterback , James.Walker@sun.com, Tom Childers , LSARC-ext@sun.com, Dean Roehrich Message-id: <494926D6.2010006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> <49491859.5060407@sun.com> <20081217161443.GE7263@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 861 I believe we can remove the two items from the list of interfaces easily... Less interfaces, less sustaining... :-) Petr Danek Duvall wrote: > On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote: > > >> I think that this is documenting the location, rather than the contents of >> these directories. >> > > Projects document exported (and imported) interfaces. Exported interfaces > are exported because the project team expects them to be imported from > other projects. If you'd like to explain in what sense these directories > are intended to be used by other projects, please do. Otherwise, the > documentation directory is Not an Interface, and the private directory full > of jar files is Project Private. Simply filling a slot in a Public > directory's namespace isn't sufficient to make an interface Public. > > Danek > From tom.childers@Sun.COM Fri Dec 19 10:08:39 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJI8dum027044 for ; Fri, 19 Dec 2008 10:08:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBJI8cuE015523 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 19 Dec 2008 10:08:39 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC400D0HYEDX000@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 11:08:37 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC4008KGYEC6I60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 11:08:36 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBJI8aDK025097 for ; Fri, 19 Dec 2008 10:08:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC400A01XVLMG00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 10:08:36 -0800 (PST) Received: from [10.0.1.5] ([98.210.99.213]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC4004UBYDSC5I0@fe-sfbay-10.sun.com>; Fri, 19 Dec 2008 10:08:16 -0800 (PST) Date: Fri, 19 Dec 2008 10:08:21 -0800 From: Tom Childers Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <494926D6.2010006@sun.com> Sender: Thomas.Childers@Sun.COM To: Petr Slechta Cc: Danek Duvall , Brian Utterback , James.Walker@Sun.COM, LSARC-ext@Sun.COM, Dean Roehrich Message-id: <4CF14315-C13A-4AF0-8C8B-3139C7D6BC4E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> <49491859.5060407@sun.com> <20081217161443.GE7263@mumak.SFBay.Sun.COM> <494926D6.2010006@sun.com> Status: RO Content-Length: 1061 With those two minor changes, I have no issues. I think we can finally close this :-) Thanks, Petr. -tdc On Dec 17, 2008, at 8:20 AM, Petr Slechta wrote: > I believe we can remove the two items from the list of interfaces > easily... Less interfaces, less sustaining... :-) > > Petr > > Danek Duvall wrote: >> On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote: >> >> >>> I think that this is documenting the location, rather than the >>> contents of these directories. >>> >> >> Projects document exported (and imported) interfaces. Exported >> interfaces >> are exported because the project team expects them to be imported >> from >> other projects. If you'd like to explain in what sense these >> directories >> are intended to be used by other projects, please do. Otherwise, the >> documentation directory is Not an Interface, and the private >> directory full >> of jar files is Project Private. Simply filling a slot in a Public >> directory's namespace isn't sufficient to make an interface Public. >> >> Danek >> > From Petr.Slechta@sun.com Fri Dec 19 12:02:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJK20Dh014953 for ; Fri, 19 Dec 2008 12:02:01 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBJK1Nmj023677 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 19 Dec 2008 20:01:59 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC5001433N68U00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 13:01:54 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC500KK03N48230@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 13:01:53 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBJK1qAj025395 for ; Fri, 19 Dec 2008 20:01:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC5001012YTJY00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 19 Dec 2008 20:01:52 +0000 (GMT) Received: from [10.162.13.159] ([85.160.35.175]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC500ENN3ML9GS0@fe-emea-10.sun.com>; Fri, 19 Dec 2008 20:01:39 +0000 (GMT) Date: Fri, 19 Dec 2008 21:01:32 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <4CF14315-C13A-4AF0-8C8B-3139C7D6BC4E@sun.com> Sender: Petr.Slechta@sun.com To: Tom Childers Cc: Danek Duvall , Brian Utterback , James.Walker@sun.com, LSARC-ext@sun.com, Dean Roehrich Message-id: <494BFD9C.1010403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> <49491859.5060407@sun.com> <20081217161443.GE7263@mumak.SFBay.Sun.COM> <494926D6.2010006@sun.com> <4CF14315-C13A-4AF0-8C8B-3139C7D6BC4E@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 1296 Thanks to everyone who participated! I believe other java applications will be able to go through the LSARC review faster... :-) Marry Christmas and Happy New Year to everyone! Petr Tom Childers wrote: > With those two minor changes, I have no issues. I think we can > finally close this :-) Thanks, Petr. > -tdc > > On Dec 17, 2008, at 8:20 AM, Petr Slechta wrote: > >> I believe we can remove the two items from the list of interfaces >> easily... Less interfaces, less sustaining... :-) >> >> Petr >> >> Danek Duvall wrote: >>> On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote: >>> >>> >>>> I think that this is documenting the location, rather than the >>>> contents of these directories. >>>> >>> >>> Projects document exported (and imported) interfaces. Exported >>> interfaces >>> are exported because the project team expects them to be imported from >>> other projects. If you'd like to explain in what sense these >>> directories >>> are intended to be used by other projects, please do. Otherwise, the >>> documentation directory is Not an Interface, and the private >>> directory full >>> of jar files is Project Private. Simply filling a slot in a Public >>> directory's namespace isn't sufficient to make an interface Public. >>> >>> Danek >>> >> > From brian.utterback@sun.com Mon Dec 22 06:48:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBMEmacp021457 for ; Mon, 22 Dec 2008 06:48:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBMEmG58011406; Mon, 22 Dec 2008 14:48:33 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KCA00C0194W3F00@brm-avmta-1.central.sun.com>; Mon, 22 Dec 2008 07:48:32 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KCA008VP94VZI20@brm-avmta-1.central.sun.com>; Mon, 22 Dec 2008 07:48:31 -0700 (MST) Received: from [129.148.9.185] (sr1-ubur-27.East.Sun.COM [129.148.9.185]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBMEmRxJ024372; Mon, 22 Dec 2008 09:48:27 -0500 (EST) Date: Mon, 22 Dec 2008 09:48:27 -0500 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <494BFD9C.1010403@sun.com> To: Petr Slechta Cc: Tom Childers , Danek Duvall , James.Walker@sun.com, LSARC-ext@sun.com, Dean Roehrich Message-id: <494FA8BB.2080702@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20081209191445.GQ7263@mumak.SFBay.Sun.COM> <49469EC9.8010801@sun.com> <4947F545.8020704@sun.com> <20081216184701.GX7263@mumak.SFBay.Sun.COM> <4947F919.3030001@sun.com> <20081216185750.GY7263@mumak.SFBay.Sun.COM> <4948DDED.8080309@sun.com> <20081217141520.GF25343@mumak.SFBay.Sun.COM> <49491859.5060407@sun.com> <20081217161443.GE7263@mumak.SFBay.Sun.COM> <494926D6.2010006@sun.com> <4CF14315-C13A-4AF0-8C8B-3139C7D6BC4E@sun.com> <494BFD9C.1010403@sun.com> User-Agent: Thunderbird 2.0.0.19pre (X11/20081201) Status: RO Content-Length: 2074 I have updated the deliverables list and the FOSS checklist with the requested changes. As there are no further issues and the fast track timer has expired, I have marked this case as "closed approved". Petr Slechta wrote: > Thanks to everyone who participated! I believe other java applications > will be able to go through the LSARC review faster... :-) > > Marry Christmas and Happy New Year to everyone! > > Petr > > > Tom Childers wrote: >> With those two minor changes, I have no issues. I think we can >> finally close this :-) Thanks, Petr. >> -tdc >> >> On Dec 17, 2008, at 8:20 AM, Petr Slechta wrote: >> >>> I believe we can remove the two items from the list of interfaces >>> easily... Less interfaces, less sustaining... :-) >>> >>> Petr >>> >>> Danek Duvall wrote: >>>> On Wed, Dec 17, 2008 at 10:18:49AM -0500, Brian Utterback wrote: >>>> >>>> >>>>> I think that this is documenting the location, rather than the >>>>> contents of these directories. >>>>> >>>> >>>> Projects document exported (and imported) interfaces. Exported >>>> interfaces >>>> are exported because the project team expects them to be imported from >>>> other projects. If you'd like to explain in what sense these >>>> directories >>>> are intended to be used by other projects, please do. Otherwise, the >>>> documentation directory is Not an Interface, and the private >>>> directory full >>>> of jar files is Project Private. Simply filling a slot in a Public >>>> directory's namespace isn't sufficient to make an interface Public. >>>> >>>> Danek >>>> >>> >> > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From James.Walker@sun.com Thu Jan 15 17:01:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0G11po0008984 for ; Thu, 15 Jan 2009 17:01:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0G11ZcD016773 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 16 Jan 2009 01:01:50 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0080HHJ1YY00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Thu, 15 Jan 2009 17:01:49 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00ENVHIZDE70@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Thu, 15 Jan 2009 17:01:48 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0G11lmx020009 for ; Fri, 16 Jan 2009 01:01:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00L01HFB4L00@mail-amer.sun.com> (original mail from James.Walker@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 15 Jan 2009 18:01:47 -0700 (MST) Received: from [172.20.25.153] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ005VIHIYTC50@mail-amer.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 15 Jan 2009 18:01:47 -0700 (MST) Date: Thu, 15 Jan 2009 18:25:54 -0700 From: Jim Walker Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] Sender: James.Walker@sun.com To: lsarc-ext@sun.com Reply-to: James.Walker@sun.com Message-id: <496FE222.3030605@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1454 I would like some clarification on jar file porting for future arc cases. findbugs plans to integrate the following project private jar files. 163 f none usr/share/lib/java/findbugs/asm-analysis-3.1.jar 164 f none usr/share/lib/java/findbugs/asm-xml-3.1.jar 165 f none usr/share/lib/java/findbugs/asm-util-3.1.jar 169 f none usr/share/lib/java/findbugs/asm-tree-3.1.jar 170 f none usr/share/lib/java/findbugs/dom4j-1.6.1.jar 173 f none usr/share/lib/java/findbugs/asm-3.1.jar 174 f none usr/share/lib/java/findbugs/jaxen-1.1.1.jar 175 f none usr/share/lib/java/findbugs/asm-commons-3.1.jar 176 f none usr/share/lib/java/findbugs/bcel.jar Which reduce down to these open source projects. BTW. the versions seem to be current. asm-*-3.1.jar http://asm.objectweb.org/ (asm-3.1) dom4j-1.6.1.jar http://www.dom4j.org/ (dom4j-1.6.1) jaxen-1.1.1.jar http://jaxen.codehaus.org/ (jaxen-1.1.1) bcel.jar http://jakarta.apache.org/bcel/ (bcel-5.2?) From an arc perspective, wouldn't it be better to integrate these jar files here, since they are all something other applications can use (ie. they are not modified for findbugs). /usr/share/lib/java/ BTW. all of these have multiple (6+) OSRs for delivery to multiple products. It would be nice if we had just one copy of each like was done for junit. Cheers, Jim p.s. The SFW c-team requires that jar files be built from source, which is also an issue for integration, but that's not arc related. From Petr.Slechta@sun.com Fri Jan 16 02:00:40 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GA0dCg021782 for ; Fri, 16 Jan 2009 02:00:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0GA0XCE008317 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 16 Jan 2009 10:00:38 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK00F056H1RV00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Fri, 16 Jan 2009 02:00:37 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK002J96GZT460@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Fri, 16 Jan 2009 02:00:36 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0GA0ZgZ014514 for ; Fri, 16 Jan 2009 10:00:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDK00B01419MG00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 16 Jan 2009 10:00:35 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK007JA6GALNH0@fe-emea-09.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 16 Jan 2009 10:00:11 +0000 (GMT) Date: Fri, 16 Jan 2009 11:00:11 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <496FE222.3030605@sun.com> Sender: Petr.Slechta@sun.com To: James.Walker@sun.com Cc: lsarc-ext@sun.com Message-id: <49705AAB.3040202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 4303 Hello, please see my comments... Petr Jim Walker wrote: > I would like some clarification on jar file porting for > future arc cases. > > findbugs plans to integrate the following project private > jar files. > > 163 f none usr/share/lib/java/findbugs/asm-analysis-3.1.jar > 164 f none usr/share/lib/java/findbugs/asm-xml-3.1.jar > 165 f none usr/share/lib/java/findbugs/asm-util-3.1.jar > 169 f none usr/share/lib/java/findbugs/asm-tree-3.1.jar > 170 f none usr/share/lib/java/findbugs/dom4j-1.6.1.jar > 173 f none usr/share/lib/java/findbugs/asm-3.1.jar > 174 f none usr/share/lib/java/findbugs/jaxen-1.1.1.jar > 175 f none usr/share/lib/java/findbugs/asm-commons-3.1.jar > 176 f none usr/share/lib/java/findbugs/bcel.jar > > Which reduce down to these open source projects. > BTW. the versions seem to be current. > > asm-*-3.1.jar http://asm.objectweb.org/ (asm-3.1) > dom4j-1.6.1.jar http://www.dom4j.org/ (dom4j-1.6.1) > jaxen-1.1.1.jar http://jaxen.codehaus.org/ (jaxen-1.1.1) > bcel.jar http://jakarta.apache.org/bcel/ (bcel-5.2?) > > From an arc perspective, wouldn't it be better to integrate > these jar files here, since they are all something other > applications can use (ie. they are not modified for findbugs). > > /usr/share/lib/java/ My personal opinion is that sharing all jar libraries is not good idea. If every application has its own copies of jars then it is independent. (Uninstallation of other application cannot brake it.) Jar files are small and today we have disks with capacity of many GBs, so it is not a problem. Especially for such small utilities like findbugs is. But that is my personal opinion. If the policy is to share jars, then I don't understand what are the rules for selecting such jars. - Any jar should be sharable? I don't think so, because some of the jars are just internal modules of the application that nobody else will need. - Any library that is generic enough and can be potentially shared by some other application? How would you measure the potential of the library to be marked as "usable to other applications"? - Is not is better to follow "natural evolution" of content in SFW repository? I mean if some application brings jars that could be shared, but nobody requires them now, then make them as private copies of the application. When some second application should be integrated and uses the same libraries, then the libraries should be made public (sharable). The question is who is responsible to do it. I would suggest that the new application should make the jars public first. Then both (the old and the new) application should be changed to use the shared jars. There is also problem with versions of the jars, because some of the jars do not contain any version information in it (like bcel.jar, or jsr305.jar). > > BTW. all of these have multiple (6+) OSRs for delivery to multiple > products. It would be nice if we had just one copy of each like > was done for junit. > > Cheers, > Jim > > p.s. The SFW c-team requires that jar files be built from > source, which is also an issue for integration, but that's > not arc related. If the policy is to compile all jars (including private jar libraries delivered with the application), then it will make porting any Java application very very hard. The standard way how O/S projects work is that they take jar libraries and use them (they do not compile them). I believe we should follow the same process. There was an argument that we should sustain the application, so we have to sustain the libraries too, so we should compile them from sources. I personally don't agree. If there is a problem with some of the libraries, the new version of the application (findbugs) will be released (with the new version of the library). This is standard way how O/S projects do handle such issues. I'm going to sustain findbugs, but the scenario when I will fix libraries is very very improbable. I believe no project that is in SFW did face such problems. If any shared jar should be ported as different project, then it means very huge amount of extra work (OSR, LSARC, RTIs, C-team review, etc.) and makes it in fact impossible to port any Java application into OpenSolaris (even such small utility like findbugs is)... From brian.utterback@sun.com Fri Jan 16 05:25:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GDPiF5011186 for ; Fri, 16 Jan 2009 05:25:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0GDPgTU028589 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 16 Jan 2009 05:25:44 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK00213FYU7N00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 05:25:42 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK001KMFYTG220@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 05:25:42 -0800 (PST) Received: from [129.148.9.177] (sr1-ubur-23.East.Sun.COM [129.148.9.177]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0GDPd1G017637; Fri, 16 Jan 2009 08:25:40 -0500 (EST) Date: Fri, 16 Jan 2009 08:25:39 -0500 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49705AAB.3040202@sun.com> To: Petr Slechta Cc: James.Walker@sun.com, lsarc-ext@sun.com Message-id: <49708AD3.4050601@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> User-Agent: Thunderbird 2.0.0.20pre (X11/20090108) Status: RO Content-Length: 3320 Petr Slechta wrote: >> /usr/share/lib/java/ > My personal opinion is that sharing all jar libraries is not good idea. > If every application has its own copies of jars then it is independent. > (Uninstallation of other application cannot brake it.) Jar files are > small and today we have disks with capacity of many GBs, so it is not a > problem. Especially for such small utilities like findbugs is. But that > is my personal opinion. > There is no problem per se, but the question is, what is the right thing to do from a product standpoint? If the jar files are never shared, then the whole discussion on versioning them did not need to take place. From a sustaining point of view, having multiple copies of things is a nightmare. Suppose a security issue comes up with one of the components? We then have to find and fix all those copies. If we do what you suggest and include pre-compiled components, then we can't fix them and we might not even know they are there. How can you ever trust a component without knowing its provenance? > If the policy is to share jars, then I don't understand what are the > rules for selecting such jars. > - Any jar should be sharable? I don't think so, because some of the jars > are just internal modules of the application that nobody else will need. > - Any library that is generic enough and can be potentially shared by > some other application? How would you measure the potential of the > library to be marked as "usable to other applications"? > - Is not is better to follow "natural evolution" of content in SFW > repository? I mean if some application brings jars that could be shared, > but nobody requires them now, then make them as private copies of the > application. When some second application should be integrated and uses > the same libraries, then the libraries should be made public (sharable). > The question is who is responsible to do it. I would suggest that the > new application should make the jars public first. Then both (the old > and the new) application should be changed to use the shared jars. The rule is simple: "Do the right thing". It doesn't seem reasonable to me that the second project must package the component, and then test both the old and new packages. It does seem reasonable to me that the first project to deliver a component should deliver that component in the best way possible. > > There is also problem with versions of the jars, because some of the > jars do not contain any version information in it (like bcel.jar, or > jsr305.jar). > There's that provenance thing again. You are arguing for delivery of executables without knowing what they are or where they came from. That is totally unacceptable from a product engineering standpoint and from an open source standpoint. -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Petr.Slechta@Sun.COM Fri Jan 16 05:55:46 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GDtjbN011669 for ; Fri, 16 Jan 2009 05:55:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0GDtgvv014712 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 16 Jan 2009 21:55:44 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK00103HCTNH00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 05:55:41 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK00MLIHCSDA10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 05:55:41 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0GDtewe010638 for ; Fri, 16 Jan 2009 13:55:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDK00101DLQRU00@fe-emea-09.sun.com> (original mail from Petr.Slechta@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 13:55:40 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK000KBHCDC7C0@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 16 Jan 2009 13:55:26 +0000 (GMT) Date: Fri, 16 Jan 2009 14:55:26 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49708AD3.4050601@sun.com> Sender: Petr.Slechta@Sun.COM To: Brian Utterback Cc: James.Walker@Sun.COM, LSARC-ext@Sun.COM Message-id: <497091CE.7060603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 5213 Brian Utterback wrote: > > > Petr Slechta wrote: > >>> /usr/share/lib/java/ >> My personal opinion is that sharing all jar libraries is not good >> idea. If every application has its own copies of jars then it is >> independent. (Uninstallation of other application cannot brake it.) >> Jar files are small and today we have disks with capacity of many >> GBs, so it is not a problem. Especially for such small utilities like >> findbugs is. But that is my personal opinion. >> > > There is no problem per se, but the question is, what is the right > thing to do from a product standpoint? If the jar files are never > shared, then the whole discussion on versioning them did not need to > take place. > > From a sustaining point of view, having multiple copies of things is a > nightmare. Suppose a security issue comes up with one of the > components? We then have to find and fix all those copies. If we do > what you suggest and include pre-compiled components, then we can't > fix them and we might not even know they are there. How can you ever > trust a component without knowing its provenance? I can see also other example, because compatibility is sometimes very tricky (and API does not mean only interfaces, but also behavior of the methods). Imagine the following situation: There is a bug in some library. You fix it (you fix only body of the method, interfaces are not touched). You replace the library, but one of the applications that use this shared library stops working. Why? Because it used the bug as normal behavior of the library and when it is fixed and the library behaves different way, the application has a problem. The similar situation is with Java VM versions. Some applications require exact version of Java, because it cannot run under newer version (something changed, even if Java should be backward compatible and the application should run on newer version of Java too). This is just for illustration. The world is not perfect. I strongly believe that nobody will fix jar libraries. If there is a problem and new library is available, we can get it and replace it. We don't need to compile it. And I know the provenance of the library. Many O/S projects use Apache commons libraries for example. Nobody compiles them, everybody just use them. I trust this library. I can get sources, but would you examine each line of the code to be sure that the library is OK? > > >> If the policy is to share jars, then I don't understand what are the >> rules for selecting such jars. >> - Any jar should be sharable? I don't think so, because some of the >> jars are just internal modules of the application that nobody else >> will need. >> - Any library that is generic enough and can be potentially shared by >> some other application? How would you measure the potential of the >> library to be marked as "usable to other applications"? >> - Is not is better to follow "natural evolution" of content in SFW >> repository? I mean if some application brings jars that could be >> shared, but nobody requires them now, then make them as private >> copies of the application. When some second application should be >> integrated and uses the same libraries, then the libraries should be >> made public (sharable). The question is who is responsible to do it. >> I would suggest that the new application should make the jars public >> first. Then both (the old and the new) application should be changed >> to use the shared jars. > > The rule is simple: "Do the right thing". It doesn't seem reasonable > to me that the second project must package the component, and then > test both the old and new packages. It does seem reasonable to me that > the first project to deliver a component should deliver that component > in the best way possible. It is fine to do "the right things". But the world is not perfect. So why some package should export jar library x.y.z-ver1.2.4 (even if it looks that it may be useful to other applications) if after 2 years nobody uses it? It is waste of developer's time. For me, the better thing would be to care about sharing when the request for it is on the table. So if some other application needs the jar, let's make it shared. But without this request, without any use case for the sharing, it does not make sense to me. The same way the applications evolve. Nobody starts with very generic modular, internationalized, secured, etc. application. At the beginning, the application is simple without these features. And only if someone really needs such feature, then it is implemented. For each feature, there must be a use case. I believe the same holds for share-ability of some jar library. If there is no use case to make it shared, we should not do it. > >> >> There is also problem with versions of the jars, because some of the >> jars do not contain any version information in it (like bcel.jar, or >> jsr305.jar). >> > > There's that provenance thing again. You are arguing for delivery of > executables without knowing what they are or where they came from. > That is totally unacceptable from a product engineering standpoint and > from an open source standpoint. > From carlsonj@phorcys.east.sun.com Fri Jan 16 05:57:01 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GDv0ST011705 for ; Fri, 16 Jan 2009 05:57:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0GDus1d014065; Fri, 16 Jan 2009 05:56:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK0010LHEXT500@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 05:56:57 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK00M40HEWD620@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 05:56:56 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0GDuur5013184; Fri, 16 Jan 2009 08:56:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0GDuulK013181; Fri, 16 Jan 2009 08:56:56 -0500 (EST) Date: Fri, 16 Jan 2009 08:56:56 -0500 From: James Carlson Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49708AD3.4050601@sun.com> To: Brian Utterback Cc: Petr Slechta , lsarc-ext@sun.com, James.Walker@sun.com Message-id: <18800.37416.223713.312930@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> Status: RO Content-Length: 1082 Brian Utterback writes: > From a sustaining point of view, having multiple copies of things is > a nightmare. Suppose a security issue comes up with one of the > components? We then have to find and fix all those copies. If we do > what you suggest and include pre-compiled components, then we can't > fix them and we might not even know they are there. How can you ever > trust a component without knowing its provenance? These issues (and more) were discussed for 1991/061. It's well worth the read. Brian's right: the big rule is that we deliver a system component only once. If there are extraordinary issues that compel a particular project to deliver a private copy of something, then those issues should be brought up and scrutinized carefully in the ARC, but the default is still to deliver common components so that all can build on them. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From brian.utterback@sun.com Fri Jan 16 06:29:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GETZsU012182 for ; Fri, 16 Jan 2009 06:29:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0GETVWk009062 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 16 Jan 2009 14:29:34 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK0010VIX6FY00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 07:29:30 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK007F9IX3EAE0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 07:29:27 -0700 (MST) Received: from [129.148.9.177] (sr1-ubur-23.East.Sun.COM [129.148.9.177]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0GETPq3044400; Fri, 16 Jan 2009 09:29:25 -0500 (EST) Date: Fri, 16 Jan 2009 09:29:25 -0500 From: Brian Utterback Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <497091CE.7060603@sun.com> To: Petr Slechta Cc: James.Walker@sun.com, LSARC-ext@sun.com Message-id: <497099C5.1060402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> <497091CE.7060603@sun.com> User-Agent: Thunderbird 2.0.0.20pre (X11/20090108) Status: RO Content-Length: 1078 Petr Slechta wrote: > And I know the provenance of the library. Many O/S projects use Apache > commons libraries for example. Nobody compiles them, everybody just use > them. I trust this library. I can get sources, but would you examine > each line of the code to be sure that the library is OK? > Maybe *you* know. Maybe. But what about the rest of the world? How am I supposed to know where you got the jar from and what is in it? And yes, at least in principle every line of code should be examined. Or at the very least, examinable. It's not open source otherwise. -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Petr.Slechta@sun.com Fri Jan 16 06:52:42 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GEqfNO012419 for ; Fri, 16 Jan 2009 06:52:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0GEqd7B052264 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 16 Jan 2009 07:52:41 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK0070YJZRVG00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 06:52:39 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK0050JJZO9D30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 06:52:37 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0GEqaSl029079 for ; Fri, 16 Jan 2009 14:52:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDK00201IB04I00@fe-emea-10.sun.com> (original mail from Petr.Slechta@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 14:52:36 +0000 (GMT) Received: from [129.157.20.124] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK00M6TJZ5NMD0@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 14:52:18 +0000 (GMT) Date: Fri, 16 Jan 2009 15:52:18 +0100 From: Petr Slechta Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <497099C5.1060402@sun.com> Sender: Petr.Slechta@sun.com To: Brian Utterback Cc: James.Walker@sun.com, LSARC-ext@sun.com Message-id: <49709F22.1050301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> <497091CE.7060603@sun.com> <497099C5.1060402@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2183 I don't want to argue more about this. I don't agree, but I can do it the requested way. I hope after the change, there will be no additional objections. You can see that I was waiting 2 months for LSARC and I presented package structure as part of the LSARC review. The LSARC is over and closed, but I have to completely change the structure of the package (even if it was accepted by the LSARC)... How many iterations (or complete restarts) can I expect? It is waste of my work. OK, if everything should be compiled (even if there are projects in SFW that do not do it), should I compile the libraries as part of findbugs project, or should I create separate project for each library (or set of libraries)? Like: asm-*-3.1.jar http://asm.objectweb.org/ (asm-3.1) dom4j-1.6.1.jar http://www.dom4j.org/ (dom4j-1.6.1) jaxen-1.1.1.jar http://jaxen.codehaus.org/ (jaxen-1.1.1) bcel.jar http://jakarta.apache.org/bcel/ (bcel-5.2?) If I can deliver shared libraries as part of findbugs package, then the other applications may have problem to access them during compilation, because SFW build system does not support dependencies (first all libraries are compiled, then all applications). The only way how to fix it is to compile findbugs as first application in the list. If I should have extra project for each library, should I start from the beginning and file new OSR, LSARC, CR, RTIs, C-team, etc. for each project? This way, porting of any simple utility like findbugs becomes a real huge project... Petr Brian Utterback wrote: > > > Petr Slechta wrote: >> And I know the provenance of the library. Many O/S projects use >> Apache commons libraries for example. Nobody compiles them, everybody >> just use them. I trust this library. I can get sources, but would you >> examine each line of the code to be sure that the library is OK? >> > > Maybe *you* know. Maybe. But what about the rest of the world? How am > I supposed to know where you got the jar from and what is in it? > > And yes, at least in principle every line of code should be examined. > Or at the very least, examinable. It's not open source otherwise. > From carlsonj@phorcys.east.sun.com Fri Jan 16 07:08:25 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GF8PQr012829 for ; Fri, 16 Jan 2009 07:08:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0GF89VW023844; Fri, 16 Jan 2009 07:08:22 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK00A09KPXRO00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 07:08:21 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK00MP2KPWD580@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 07:08:21 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0GF8Krf013505; Fri, 16 Jan 2009 10:08:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0GF8KIl013502; Fri, 16 Jan 2009 10:08:20 -0500 (EST) Date: Fri, 16 Jan 2009 10:08:20 -0500 From: James Carlson Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <49709F22.1050301@sun.com> To: Petr Slechta Cc: Brian Utterback , LSARC-ext@sun.com, James.Walker@sun.com Message-id: <18800.41700.500220.78181@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> <497091CE.7060603@sun.com> <497099C5.1060402@sun.com> <49709F22.1050301@sun.com> Status: RO Content-Length: 647 Petr Slechta writes: > OK, if everything should be compiled (even if there are projects in SFW > that do not do it), should I compile the libraries as part of findbugs > project, or should I create separate project for each library (or set of > libraries)? Like: I see no reason that the existing case couldn't just note these as additional exports. Four lines of text; done. Don't make a mountain out of a molehill. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From storycrafter@gmail.com Fri Jan 16 07:12:29 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GFCT30012872 for ; Fri, 16 Jan 2009 07:12:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0GFCLsj003030; Fri, 16 Jan 2009 15:12:24 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK0081BKWLX900@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Jan 2009 07:12:21 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK005WJKWK9240@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Jan 2009 07:12:20 -0800 (PST) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0GFCKVq004886; Fri, 16 Jan 2009 15:12:20 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay24i.sun.com with ESMTP id BT-MMP-3049272; Fri, 16 Jan 2009 15:12:19 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-62065731; Fri, 16 Jan 2009 15:12:19 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.158] [74.125.46.158]) by relay24i.sun.com with ESMTP id BT-MMP-10992872; Fri, 16 Jan 2009 15:12:19 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 9so696069ywk.68 for ; Fri, 16 Jan 2009 07:11:29 -0800 (PST) Received: by 10.100.14.10 with SMTP id 10mr146481ann.119.1232118688988; Fri, 16 Jan 2009 07:11:28 -0800 (PST) Received: by 10.100.32.13 with HTTP; Fri, 16 Jan 2009 07:11:28 -0800 (PST) Date: Fri, 16 Jan 2009 09:11:28 -0600 From: Mark Martin Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <497091CE.7060603@sun.com> To: Petr Slechta Cc: Brian Utterback , LSARC-ext@sun.com, James.Walker@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=N+dwWbokHDlkiEQsrJ6DOfoZZw6j3SI0ZmdE6Eiyy4E=; b=OwHkDU5okRgp2V8q3Z2cmMIxYLznjmAzVYQIhzqx4msNA3yog6g9Ym3JSH2Klut2Gx Mkoint0pKp7tdA/0kvXfK+Urgy6Sv8Ot2GMlB264K8jt0HJN/Ef8QWGP89y8FL2z2A/D rxTIct5mh9zNtOoAUQ30dNUYZhJ5+J8XHcZlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hDPKU5Ebjr2/PkwhXsG6ztVf33cn/VtdCIiJTDvSzWV/DMzGm1EqSErN+vW1jFEtcq Y39XtG03nqaiFUXpBGKIy+bOXoKzskVHC1fxhKOn5Yn3z9ka04li/AOCOrJsag96mlpH 6biVZCijiSKHmRrgoLpSAwHCyIUn3fNTyPd90= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.152sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> <497091CE.7060603@sun.com> Status: RO Content-Length: 2552 On Fri, Jan 16, 2009 at 7:55 AM, Petr Slechta wrote: > > I strongly believe that nobody will fix jar libraries. If there is a > problem and new library is available, we can get it and replace it. We > don't need to compile it. Trust, but verify.... http://blogs.zdnet.com/security/?p=2016&tag=nl.e589 http://it.slashdot.org/article.pl?sid=08/12/29/0155249 http://news.bbc.co.uk/1/hi/technology/7583805.stm And that's just the last few months. Repeatable builds is at least one of the principles at play here. I, as a consumer of the software, might like to repeatably and reliably rebuild the binary artifacts from source myself, using the appropriate tools and process. While I do agree that conventionally, most Java based projects do practice bundling pre-built libraries in their distributions, this isn't most Java based projects. There is a whole community out there that expects to see the source behind it to preserve their right to tinker with it. Partly because this same community conventionally uses only internally housed meta data describing the library (whereas traditional binary libraries at least provide hints via naming), it's difficult to tell versions of java libraries on their face. That means that if you ship the binary I would expect to see a very detailed accounting the chain of custody of this jar -- what EXACT version was it built on?, where did it come from EXACTLY?, how did THEY build it?, who touched it afterwards?, was it modified in any way? How do I rebuild it myself?, etc. Just provide the source and there's no question. I raised the question of whether there should be a rule or advice requiring that java jars be explicitly named according to version (much like other libraries), and that some serious thought given to how we're going to handle 233,242 private copies of dom4j-guess-my-version-and-lineage.jar, but the jars included were declared project private which negated any such requirement and the case went through. I believe you had renamed the jars just before this last point was made. I have no problem with that, personally, other than to sigh quietly and move on, but it looks like others are catching the same thing now that you're delivering. I fear that in the worst case you may setting the precedent that I was asking about. If Sun's internal policies (c-team? x-team?) requires source for all library components then that's between you and them. I'll tell you as an external community participant -- not bundling the source will be a mistake. From storycrafter@gmail.com Fri Jan 16 08:04:14 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0GG4D7M018261 for ; Fri, 16 Jan 2009 08:04:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0GG4CbM015859 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 17 Jan 2009 00:04:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDK00B1HNAYZK00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 08:04:10 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK005P1NAW9080@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 08:04:08 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0GG47nJ000824 for ; Fri, 16 Jan 2009 16:04:08 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-2736548 for LSARC-ext@sun.com; Fri, 16 Jan 2009 16:04:07 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-58878 for LSARC-ext@sun.com; Fri, 16 Jan 2009 16:04:07 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.157] [74.125.46.157]) by relay1i.sun.com with ESMTP id BT-MMP-27583885 for LSARC-ext@sun.com; Fri, 16 Jan 2009 16:04:07 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 9so709944ywk.68 for ; Fri, 16 Jan 2009 08:04:06 -0800 (PST) Received: by 10.100.13.6 with SMTP id 6mr2101792anm.9.1232118818913; Fri, 16 Jan 2009 07:13:38 -0800 (PST) Received: by 10.100.32.13 with HTTP; Fri, 16 Jan 2009 07:13:38 -0800 (PST) Date: Fri, 16 Jan 2009 09:13:38 -0600 From: Mark Martin Subject: Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] In-reply-to: <18800.41700.500220.78181@gargle.gargle.HOWL> To: Petr Slechta Cc: James Carlson , Brian Utterback , LSARC-ext@sun.com, James.Walker@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=L9WRxFYtf2W0wya6OWOUPXF/pLWO3JTuB1HMMsMimUQ=; b=bSpKswZ2ak4bDv02t8KAyLZyiTh3VqPDii6hrHF/WH9tIorEV5avL0Oo5VdPGu9Zdn Tf0HJFTkuXFXKB3SN4D7sCCmZs9m3AgcZ81RK2qwtvuDVKB0j2TlFt5ay8RqMUEbbct6 NY4bnj4dmqthtA1YOOuUjmlAO+cQxLrSdmV3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uu/ovriXVZCl7OhyDlleBya7C2rOGEiy4iDb9E86G3E/fVeGgJRCqpS2Z7ek7PomrG kP6h74Il9IaOY3+c5lfj6FuFFP+G3/VBg3O7KWy5OUBM0QkIowvLorFGpdiT4tvlukz5 Eh2u4OsPAgKAqgNbZNSr95wKFCmtZRsh08CBk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.134sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496FE222.3030605@sun.com> <49705AAB.3040202@sun.com> <49708AD3.4050601@sun.com> <497091CE.7060603@sun.com> <497099C5.1060402@sun.com> <49709F22.1050301@sun.com> <18800.41700.500220.78181@gargle.gargle.HOWL> Status: RO Content-Length: 518 On Fri, Jan 16, 2009 at 9:08 AM, James Carlson wrote: > Petr Slechta writes: >> OK, if everything should be compiled (even if there are projects in SFW >> that do not do it), should I compile the libraries as part of findbugs >> project, or should I create separate project for each library (or set of >> libraries)? Like: > > I see no reason that the existing case couldn't just note these as > additional exports. Four lines of text; done. > > Don't make a mountain out of a molehill. +1