"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." But with maven you've already done this with the dependency definitions. It wouldn't have compiled otherwise. Maven will also take care of dependency dependencies and let you specify packaging intent. The plugin then needlessly does a lot of bytecode inspection just to figure out what maven already told you was needed. As a stand-alone tool that is slick, as a maven plugin it is redundant and confusing. What we are saying is let the pom drive the packaging and the classpath. Let the plugin do the neat Import/Export stuff it is doing now. We aren't trying to change how bnd behaves, just how the new plugin behaves. If they are so tightly coupled that you can't change one without changing the other then perhaps that is the issue that needs to be addressed. Why oh why would you even bring up the jar vs. package debate? For better or worse .jar is the standard "packaging" mechanism and packages have been regulated to namespace duty. ;) As long as code is delivered via .jars why don't we keep it in that format? I don't want to second guess why things are packaged as they are. We are just trying to keep our bundles neat and organized. :P -Aaron -----Original Message----- From: Niclas Hedhman on behalf of Niclas Hedhman Sent: Wed 12/6/2006 8:53 PM To: felix-dev@incubator.apache.org Subject: Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles) 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
