Re: [equinox-dev] Alternate Extension Point namespace

["Richard S. Hall" <heavy@xxxxxxxxxxxxxx>]

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

>