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