Niclas Hedhman <[EMAIL PROTECTED]> wrote on 09/19/2005 12:33:41 PM:
> On Tuesday 20 September 2005 00:07, Jeff McAffer wrote:
> > 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.
>
> Huh?? Example;
>
> public class A extends B
> {
> public A()
> {
> System.out.println( "Message: " + getMessage() );
> }
> }
>
> public class B extends C
> {
> }
>
> public class C
> {
> protected String getMessage()
> {
> return "Hello";
> }
> }
>
> Are you saying that it is a legal construct to have a Classloader for A
that
> does not have class C visible?? And yet, that the getMessage() is called
> properly?
You are confusing the ability of a CLASS to see things in its inheritance
chain and that of a BUNDLE's classloader to see these things. In your
example, add the following class D to Bundle A. Remember, Bundle A does
not import or require any part of C.
public class D {
Class foo() {
return C.class;
}
}
The point here is that your example bundle A should compile and run just
fine without any dependencies on C. Howeover, for the compilation of A to
actually succeed, class C must be available and visible on the classpath
at compile time. The classic way of doing this is to add its jar
(whatever) to the classpath. Happiness.
Class D in bundle A however should fail to compile since Bundle A does not
state that it depends on C. That is, C is not on A's classpath at
runtime. Without additional technology, having C's JAR on the classpath
while compiling A makes this impossible.
Conclusion, the class loading and class visibility rules used by the
compiler get more complex. The Eclipse JDT compiler has a number of
capabilities in this area. That is what allows the Eclipse PDE to report
errors to you immediately when you reference classes that are not going to
be available to you at runtime. To make this work in something like Maven
(or even our build technology) however requires the build tooling to
generate compiler inputs that describe the filtering etc. To do that,
requires a decent model of the components and how they are wired together.
>
> Also;
> <quote>
> So, any direct reference to C's classes from A should fail
> </quote>
>
> Are you talking about inner classes in C, or is "A extends B extends C"
some
> form of "bundle" inheritance, or something??
See above.
> > I will leave
> > the religious arguments about Require-Bundle and Import-Package aside
and
> > note that both are part of the spec.
>
> Ok, even though the rumour is that it was introduced to ease migration
within
> Eclipse ;o)
There are technical merits and drawbacks to both. Use the one that makes
you happy.
> > Are you suggesting that Maven should be unable to build bundles that
use
> > Require-Bundle?
>
> No. I thought I said that having a Maven dependency resulting in a
> Require-Bundle entry in the manifest is not the right solution.
...
> That would imply that the Maven plaugin has a mechanism to create the
> Require-Bundle entry, but require some form of additional "enable".
Here there is a mindset difference. To me Maven does not create the
dependencies or entries, the developer does. The developer is the one who
knows how and why they depend on something. She may express that in a
MANIFEST.MF or in a .pom. That is just syntax. What is important is that
Maven (or any other tool) cannot fully reverse engineer the dependencies
from just the code. Maven cannot likely, for example, figure out the
right version range to specify all on its own. What about all the other
directives and alternatives allowed by OSGi? Similarly, Maven should not
be expected to figure out if a dependency should be expressed using
Import-Package or Require-Bundle. There could be a default mode but Maven
should expect and fully support the default to be set either way and allow
people to override that detail in a first class way.
Jeff
