[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Alternate Extension Point namespace

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.

-> richard