Hi,
Please see my comments inline.
Thanks,
Raymond
[snip]
Good requirement, but I don't think that the current manifest +
tuscany-all JAR solution is a good one (for example it mixes APIs and
internals in the same JAR, doesn't work well with IDEs, works only for one
big distro, requires different settings in J2SE and webapps)
IMHO, the all-in-one package pretty much defeats our modularity. For
example, all module activators will be called even the extension won't be
used at all. Two extension cannot have different versions of a 3rd party
jar.
Here's what I'd like to see as a user:
- a short list of API JARs that I can add to my dev compile/build path
- a single small launcher or bootstrap JAR that takes care of
bootstrapping the Tuscany runtime
This is similar to JEE launchClient. If I can invoke the Launcher directly
in java, I would be happy.
- the launcher should detect the presence of installed extensions in a
particular Tuscany installation
+1.
- as a user / app developer I should not have to know the list of JARs
from all these extensions.
Do we expect the launcher to be smart enough to pick the right set of
extensions based on the SCA assembly?
That's what I've been trying to do with the Node launcher and the library
provided by the Tuscany Eclipse plugin. More work is required to get that
vision in place (as the current launcher is still pretty rudimentary and
only scans an installation directory for JARs).
There's a good extension registry mechanism in Eclipse Equinox [1]. It
would allow us to rely on a robust mechanism for detecting installed
extensions, tracking what they provide in an extension registry [2], and
use a more user friendly syntax for registering extensions using
plugin.xml files. If we start to integrate more with OSGi I think we
should just use it (maybe in combination with what we currently have with
META-INF/services for the cases where we don't use OSGi).
We can have a SPI so that different mechanism of extension discovery can be
plugged in. I would prefer to see both OSGi and META-INF/services based
approaches available.
[1] http://www.eclipse.org/equinox/
[2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/
-- Sebastien
