Raymond Feng wrote:
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.
That's what I was trying to convey too.
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?
Not so fast. I'm trying not to mix these different aspects. That would
be a separate step.
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.
ExtensionRegistry is designed for that, it was modeled after the Eclipse
IExtensionRegistry. I had been careful at the time to not put anything
in it that wouldn't map easily to IExtensionRegistry.
prefer to see both OSGi and META-INF/services
based approaches available.
Me too.
[1] http://www.eclipse.org/equinox/
[2]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/
-- Sebastien
--
Jean-Sebastien
