On Thursday 07 December 2006 00:54, Aaron Siri wrote: > What if we did away with <Private-Package> (or detect a special value) and > just assume that all maven jar dependencies are required by the bundle > packages with packaging of the jars honoring the dependency definitions > (i.e. compile, provided, etc.)? The classpath is added to the manifest. > You can Export-Package/Import-Package as done today. Could this work?
I have not yet taken a proper look at bnd, but your suggestions doesn't sound sound... ;o) What Peter's tools has done so far, is to traverse the bytecodes and locate all the packages that are referenced one way or the other. A task not fit for humans. Now, it makes a lot sense to me that the tool is *not* authorative in the normal case, but defaults to something useful for the average idiot like myself. I assume you are refering to such defaults... That can probably be achieved, once the principles are agreed upon. Private-Package sounds like a short-cut to "full review" of the found packages and essentially Export-Package vs Private-Package is analogous with "allow" vs "deny" in Httpd server. Further, packaging can be done in three ways; 1. embedding - Put the dependent jar file of classes into the Bundle jar. 2. inlining - Put the dependent classes into the Bundle jar 3. external - Reference to the requirement in Import-Package/Require-Bundle The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter, myself, Richard (sorry guys) grew up in days where resources were not abundant, bark was used as flour and Jack the Ripper was the real reality show for whores in London, so we get sick in the stomach when we see a 2MB jar file included in a bundle just because a single 2kB class is referenced. The point Peter always tries to make is that the Jar is a Java after-thought, a hack and that Sun actually had it more right from day 1, in that the package is the natural "container" of classes, and it was only lacking proper versioning and other annotations from the start. We should be able to ignore the Jar itself, take it for what it is; A ZIP file for easy transport. Maven, other build systems, the JVMs classpath and endless other systems assumes that the jar file carries additional significance, such as being a unique identifier of its content, or that the content will only reside in jar files that follows this particular naming conventions and if the classes resurface elsewhere, then "elsewhere" is raping someone elses work. Ok, a lot of rambling...<stop/> Cheers Niclas
