Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
Sent: Wednesday, August 27, 2008 10:38 AM
To: <[email protected]>
Subject: How to build a Tuscany OSGi environment?
I'm trying to build a Tuscany environment that includes some of the latest
Tuscany OSGi integration.
My use case is that I want Tuscany to bootstrap OSGi for me when I start a
Tuscany node, as it'll help the node load different levels of runtime
extension and dependency bundles. I want to start with Equinox for now
(I'll test with Felix later).
We have both Equinox and Felix. Felix is better tested ATM.
I have some questions:
What Tuscany modules do I need to add to my POM as dependencies?
If you use tuscany-node-launcher-osgi to launch the node, you will need to
have dependencies to compile your app (such as sca-api and node-api). The
other tuscany and 3rd party runtime jars (bundles) will be discovered from
TUSCANY_HOME and TUSCANY_PATH system properties or environment variables.
What's the difference between modules extensibility-osgi and
extensibility-equinox?
extensibility-osgi use the OSGi bundles to discover tuscany runtime
extensions/extension points using the META-INF/services pattern.
extensibility-equinox is added as a place holder to support Eclipse
plugin.xml based extension/extension point registry. So far it's still
pretty much the same as extensibility-osgi.
What are these two modules responsible for?
node-launcher-osgi has a compile dependency on Felix, can this dependency
be pushed to another module?
I'm struggling a bit here on where we should provide the pluggability for
OSGi runtimes such as Equinox or Felix. There are a few options:
1) Have different OSGi launchers for Felix and Equinox
(tuscany-node-launcher-osgi uses Felix at this point)
2) Define a SPI to discover OSGi runtimes based on the service discovery
pattern (maybe go into the extensibility-osgi, but it's kind of chicken-egg
issue. The full tuscany runtime service discovery will only be available
once the tuscany runtime is bootstrapped into the OSGi).
3) Use brute-force to see which OSGi runtime is on the classpath (See
tuscany-osgi-runtime module)
Shouldn't the dependencies on the OSGi JARs in node-launcher-osgi have
scope 'provided' instead of 'compile'?
It could be. What would be the user experience to use the launcher? If we
use a command line to launch the OSGi node. Then the less jars are required
for the launcher, the better. Maybe we should have a "launcher" folder under
TUSCANY_HOME to contain a small set of jars for the purpose of launching.
Thanks
--
Jean-Sebastien
