ant elder wrote:
On Thu, May 1, 2008 at 12:40 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
<snip>
Here's what I imagined we'd do:
1. add OSGi entries to each of our JAR manifests
2. have developers maintain them and pay attention to imports/exports
3. use the OSGi build to detect API and SPI import/export violations
4. find the best way to OSGi-enable 3rd party dependency JARs
I realize that my suggestion [1] is not very popular and most people on
this list would prefer to come up with bigger bundles grouping several of
our JARs/modules. I don't think that the 'bigger aggregate bundle' approach
will work, but I'll be happy to watch people try it :) if they want to.
Perfectly ok but would you say a bit more about why you don't think the
bigger aggregate bundle approach will work? I like the sound of less bundles
as it seems like it could be easier to use but if you know of issues it
would be nice to hear them now.
...ant
A few issues:
- We're already running into problems where modules are not fine grain
enough, some of our implementations/bindings can't be used to
introspect/represent SCA components and bindings without dragging the
whole runtime. Aggregating more will make that worse.
- Shared 3rd party or internal dependencies will make it difficult to
create these big bundles, unless you copy them into each bundle, or
create a bundle for these shared dependencies. Once you've gone through
that exercise you'll get really close to 1 bundle <-> 1 module.
- Aggregate bundles will make it more difficult to use different levels
of dependencies. For example if our BPEL and XQuery implementation
extensions need different levels of Saxon, you can't put them in the
same bundle.
and I'm sure you'll find more issues if you actually try.
--
Jean-Sebastien
