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

[Petr Slechta]

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

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

[Petr Slechta]

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. 

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

[Petr Slechta]

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

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

[James Carlson]

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 Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

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

[Brian Utterback]

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

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

[Mark Martin]

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

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

[Mark Martin]

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.

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

[James Carlson]

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 Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

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

[Brian Utterback]

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

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

[Jim Walker]

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.jarhttp://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.

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

[Brian Utterback]

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

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

[Petr Slechta]

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

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

[Tom Childers]

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

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

[Petr Slechta]

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
>   

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

[Petr Slechta]

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

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

[Brian Utterback]

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

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

[Brian Utterback]

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 NameClassification   Comments
>---  
> --
>JAVA_HOME   committedenvironment 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, I

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

[Danek Duvall]

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

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

[Danek Duvall]

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

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

[Petr Slechta]

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
>   

findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008] (correction)

[Petr Slechta]

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

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

[Petr Slechta]

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

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

[Danek Duvall]

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

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

[Danek Duvall]

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

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

[Petr Slechta]

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

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

[Jim Walker]

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

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

[Tom Childers]

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

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

[Petr Slechta]

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
>   

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

[Mark Martin]

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? 

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

[John Plocher]

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

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

[Danek Duvall]

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

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

[Tom Childers]

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

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

[Petr Slechta]

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 

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

[Tom Childers]

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

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 

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

[Brian Utterback]

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

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

[Brian Utterback]

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

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

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

[Tom Childers]

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

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

[Lloyd Chambers]

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

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

[Peter Tribble]

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

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

[Dean Roehrich]

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

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

[Brian Utterback]

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

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

[Lloyd Chambers]

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

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

[Lloyd Chambers]

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

Building a coherent and comprehensive Java development environment on OpenSolaris (was Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008])

[Ceri Davies]

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

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
-- 
That must be wonderful!  I don't understand it at all.
  -- Moliere
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 

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

[Joerg Schilling]

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 at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
   js at cs.tu-berlin.de(uni)  
   schilling at fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

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

[Darren J Moffat]

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

Building a coherent and comprehensive Java development environment on OpenSolaris (was Re: findbugs [LSARC/2008/642 FastTrack timeout 10/27/2008])

[John Plocher]

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

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

[Brian Utterback]

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

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

[Richard L. Hamilton]

> 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

You may be right.  While I don't like that not just that, but all
the ImageMagick commands were rather generic words
("display", "animate", etc), the simple fact is that regardless
of who was first, probably far more people know of and use
ImageMagick than your command, however worthwhile it may be.
And on that basis alone, I wouldn't care to argue that they should
change their name(s), let alone that anyone who uses it in a script
should change their scripts too.

Perhaps you need to choose your battles more selectively.

You could always keep your stuff with your names, in a well-known
separate directory (in /opt, preferably).  People wanting a tool of
yours with a name that conflicts with some other name would just
put the bin subdirectory of that at the start of their PATH.  That
should result in the least breakage, which IMO is always the bottom line.
--
This message posted from opensolaris.org

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

[Petr Slechta]

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 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.
>>
>> 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 STABILITYNOTES
>>>
>>>SUNWfindbugs committedpackage name
>>>
>>>/usr/bin/findbugsuncommitted  startup script
>>>/usr/findbugsuncommitted  root directory for
>>>   
>
> Shouldn't that be under /usr/lib or /usr/share, rather than directly under 
> /usr?
>
>   

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

[Petr Slechta]

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

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

[Petr Slechta]

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 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.
>
> 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 STABILITYNOTES
>>
>>SUNWfindbugs committedpackage name
>>
>>/usr/bin/findbugsuncommitted  startup script
>>/usr/findbugsuncommitted  root directory for 
>> FindBugs installations
>>
>>
>> Imported Interfaces:
>>
>>NAME STABILITYNOTES
>>
>>JAVA_HOMEcommittedenvironment 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 
>>

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

[Jyri Virkki]

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 at sun.com - Sun Microsystems

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

[Peter Tribble]

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 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.
>
> 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 STABILITYNOTES
>>
>>SUNWfindbugs committedpackage name
>>
>>/usr/bin/findbugsuncommitted  startup script
>>/usr/findbugsuncommitted  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/

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

[James Carlson]

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 Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

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

[Dean Roehrich]

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

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

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

[Dean Roehrich]

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.

Dean

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

[Tom Childers]

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

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

[Tom Childers]

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.

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 STABILITYNOTES
>
>SUNWfindbugs committedpackage name
>
>/usr/bin/findbugsuncommitted  startup script
>/usr/findbugsuncommitted  root directory for  
> FindBugs installations
>
>
> Imported Interfaces:
>
>NAME STABILITYNOTES
>
>JAVA_HOMEcommittedenvironment  
> 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
>