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