findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008]

[Petr Slechta]

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