one context for multiple bundles
Is it possible to combine spring xml config files from different bundles into one Spring context? (This is probably against the idea of Spring DM but see my detailed explanation below why I would like to do this.)
I tried this by making an extra bundle "a" with one Spring xml file that uses several lines like
where the first context file is inside bundle b and the second in bundle c. Unfortunately the Spring extender cannot find xml files from other bundles this way.
<import resource="context-from-bundle-b.xml" />
<import resource="context-from-bundle-c.xml" />
Gory details below, skip at own will
We have an Eclipse workspace that contains some plain java projects (buildable by Maven): one core java project and several different java projects that each add an aspect to beans of the core project by having extra spring xml context files. These need to be combined into one Spring context.
Furthermore we depend on classpath scanning to instantiate the necessary beans.
This is no problem at all outside of OSGi: we have one "integration" project that depends on all the java projects so that we can get everything on one classpath. We use this to start up a non-osgi server.
However, we need to use Eclipse RCP for the client which requires our code to be an OSGi Bundle. Again we have no problem at all using the maven bundle plugin to build one bundle from multiple java projects. Having everything in one bundle works fine for us.
However, everytime we change only the tiniest bit in one java file we need to rebuild the entire bundle and put the resulting jar on the target platform. This drains programming efficiency enormously. We would like to be able to use Eclipse's incremental compiler and source code linking.
One possible solution for this is to make all our java projects into OSGi bundles/Eclipse plugins. But when we do this, each project will get it's own Spring context so that classpath scanning and AOP across java projects will not work the same way as before.
One solution which I unfortunately must take if everything else fails is to put all our code into one java project and use a package-per-module structure.
So the other idea I have is by making each project an OSGi bundle that simply exports everything and have our "integration" project be an OSGi bundle that depends on each of them and combines all spring xml configuration into one context.
I know it is possible to do this by placing each spring context file into the "integration" project but then our "unit" tests cannot find their spring context anymore.
Another way for the xml file merging would be to make each project an OSGi fragment on the core project. But a bundle can not use interfaces and classes defined in fragments if they only depend on the fragment host bundle.
extender pattern, extension points, ...
Well here is my own answer at the moment...
I think for my problem there is no escape from putting the boilerplate code containing "system bundle" (what I called Olga) into one Eclipse project instead of one project per aspect.
Registering domain model entities and instantiating and exposing dao's/services could ultimately done by using an extender pattern of our own or by using equinox extension points but I don't see how this works nice with Spring-DM so I will not start this adventure at the moment and just put our domain model in the same bundle....