Daniel Fagerstrom <[EMAIL PROTECTED]> wrote on 09/19/2005 05:11:12 AM:
> Brett Porter wrote: > ... > > >It sounds to me like having the packaging is the right way to go - its a lot > >less work for the user when using defaults. It's entirely possible to do > >both with one plugin as well if that's valid, but it will add some confusion > >to the mix if its unnecessary. > > > > > ... > > Agree about that packaging is the way to go. > > Another question: how should we handle dependencies? IIUC, while > building a bundle the current plugin gather all jars it depends on, put > them in the resulting bundle and add them on the Bundle-Classpath. That > is good as long as the jars that the bundle depends on not are bundles, > but if they are bundles they should not be included in the resulting > bundle. Furthermore when a bundle A depends on another bundles B, it is > not enough to just put B on the classpath while compiling A. The > classloader used while compiling A must be OSGi aware and only make > available those packages that are exported by B and this also in the > case where the exported package is in an embeded jar. > > This far when I have built bundles with Ant I have exploded bundles with > embeded jars and put the embeded one on the classpath, but that is > obviously not a satisfying solution. How can this be solved with M2? Is > it possible to give a classloader to the compiler rather than an > ordinary classpath, so that we can use an OSGi aware classloader while > compiling? If we use "packaging" the plugin could also chose to embed > dependencies that has package type "jar" and not embed dependencies of > type "osgi-bundle". For added fun it is not just B's immediate dependencies (via Require-Bundle or Import-Package) and their exports but all of their prerequisites (transitively) that need to ba available when compiling A. Further, visibility is very much in the eye of the beholder. Consider A extends B and B extends C. A, B and C are all in different bundles (by the same name). Assume that bundle A required bundle B and B requires bundle C. To compile class A, classes B and C have to be available. However, the code in bundle A is not necessarily allowed to see the code in bundle C. In a separate usecase, bundles B and C may both export packages Foo and Bar. Bundle A may import Foo and Bar but may get Foo from B and Bar from C. This presents an ordering problem. If B and C are simply added to the compile path for A, one of Foo or Bar will be incorrect. All of this to illustrate that matching the compile-time structure to the runtime structure is quite important. Jeff
