> Jeff wrote; > > "A extends B and B extends C" --> Sorry, it is illegal in Java to say that A > has visibility of B but not C if you have inheritence hierarchies. A WILL be > a subtype of C, whether you like it or not. I must assume you mean something > else, but can't figure out what.
There is Java visibility and there is the ability of A to actually directly reference C. Of course class C has to be available to load class A but that does not mean that bundle A's classloader has to be able to see class C. It just needs to know someone (e.g., bundle B) who can. So, any direct reference to C's classes from A should fail unless A explicitly states a dependency (Import-Package or Require-Bundle) that makes them visible. At build/compile time, this means that setting up the classpath for compilation is more complicated. > And as Richard noted on KF mailing list, Require-Bundle seems to be a bad new > feature which I have a hard time to see the benefit of, compared to a > Require-Service counter-part. Any suggestion that Maven dependencies are > somehow linked to Require-Bundle is suspect to say the least. Note that my points wrt visibility were independent of Require-Bundle. You can set up the scenario us Import-Package just as easily. I will leave the religious arguments about Require-Bundle and Import-Package aside and note that both are part of the spec. Are you suggesting that Maven should be unable to build bundles that use Require-Bundle? Note also that Import-Service, while defined in the spec, is toothless at runtime (it is informational only) and is not particularly relevant to building. It is however of potential interest when choosing sets of bundles to deploy into a runtime. Jeff
