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.