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".
/Daniel
