[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Alternate Extension Point namespace
- From: "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
- Date: Fri, 02 Dec 2005 09:33:21 -0500
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 1.5 (X11/20051025)
Peter Kriens wrote:
Jeff McAffer wrote:
JM> As for import package use, yes, this can be liberating and we
JM> will likely start using this more. There really is no right
JM> answer though. It actually a question of granularity. Package
JM> dependencies are not inherently better/different than bundle
JM> dependencies. They are just a different grain size. Every point
JM> (good or bad) one can make about bundle dependencies wrt packages,
JM> can be restated as a point about package dependencies wrt classes
JM> (just replace "bundle" with "package" and "package" with "class").
JM> Then you can do the same thing with classes and methods or go up
JM> and talk about features and bundles.
I think you ignore the point that Olivier made. Package dependencies are
a dependency on "what", bundle dependencies are "where/who". It is not
just a matter of granularity.
Bundle dependencies miss substitutability. A bundle with
bundle symbolic name X, version Y must always have the same
constituents. Packages, especially specification packages, can be
substituted at will. More important, it allows different providers to
provide a "part" of the solution.
I couldn't agree more. There definitely is a difference between bundle
dependencies and package dependencies, package contents (i.e., classes)
are the actual artifacts that the JRE needs to execute the application.
A bundle is simply a packaging format. You may want to argue that a
package is "just a packaging format" too, but this is not correct since
packages play a special role in the Java world.