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 at 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 at sun.com. >>>>>>>>>> >>>>>>>>>> I am wondering what requirement we are trying to fill with this >>>>>>>>>> project. FindBugs is downloadable, gets updated frequently, >>>>>>>>>> and is not >>>>>>>>>> prepackaged on any other platform I know of. The version you >>>>>>>>>> are >>>>>>>>>> shipping is already out of date; the 1.3.6 release became >>>>>>>>>> available a >>>>>>>>>> few days ago. >>>>>>>>> >>>>>>>>> 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 >>>> >>> >> >
