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

Reply via email to