On Jan 3, 2010, at 5:53 PM, Ivan wrote:
<snip>
I will try the solution about dividing the ear as multiple bundles,
the ear itself is one, all the modules it contains are the others,
and it is possible to use require-bundle to connect the module
bundle to the ear bundle.
I'd prefer to avoid require-bundle. I was thinking of modifying the
pax url handler so that we could continue to repackage the ear as we
do now, but have the car file contain several bundles corresponding
to the different modules inside. We could perhaps imitate jar urls
and append !<moduleName> to point to an "internal" bundle. If we
did this the car would still be a single artifact in maven but would
supply all the bundles at once.
Yes, require-bundle did not have a good reputation in the OSGI
world, but in this scenario, I think we could use it to reduce the
complexity.
Keeping the same package way is a good choice, for currently,
the repository directory is a really 'repository', Geronimo never
loads any class from it, ^_^. But if in that way, the file is not a
standard bundle, and it only works for the special url handler.
Well, after the bundle gets extracted by the url handler it's a plain
ordinary bundle. The car-with bundles-inside is really just a
delivery mechanism. I'm pretty sure it would be easy to implement,
but might not be a great idea long term. It might be convenient until
we find something better. On the other hand it might get popular in
other contexts.
I forgot to mention that the other approach that seems promising to me
is to use the application bundle idea from the aries project.
thanks
david jencks
One thing I am thinking is that how to generate the exports for the
ear bundle, maybe the deployer might need use something like asm to
scan all the library files.
I think we should look into using BND for this.
Yes, BND should help us.
thanks
david jencks
<snip>
