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 >> >
