Aaron Siri wrote:
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
Well, the OSGi framework works in terms of packages, not JARs.
-> richard
-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
