Simon Nash wrote:
ant elder wrote:
On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
I'd like to discuss the following: "What distro Zips are we building
and
what do they contain?"
I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need
I was thinking about the following binary distro zips:
- tuscany-core.zip - The base that everybody needs.
core assembly model and runtime
Java APIs, Java components
- tuscany-web.zip - For WS and Web developers
WS binding, Web 2.0 bindings, Scripting components, Widget components
- tuscany-jee.zip - For JEE app integration
EJB, RMI and JMS bindings, Spring components
- tuscany-process.zip - For process development
BPEL and XQuery components
- tuscany-all.zip - all of the above
Note that I'm not trying to tackle release cycles and the potential for
releasing the above zips independently in this discussion and I'm
assuming
that we release all of the above together.
I'm also assuming that the relevant samples are included in each zip.
This email was from 1/22/08, generated a lot of discussion for about 3
weeks, lots of opinions, no conclusion, no commits :)
No commits as we haven't found much consensus yet.
I still think the same as what I had posted then, plus additional ideas:
- Use OSGi exports/imports to export clean SPIs, hide internals, and
refine
the contents of the distros and their dependencies.
Disclaimer - Please don't get me wrong I'm not saying that one distro ==
one
OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.
The term "enforcing" seems to suggest that there might be an OSGi
dependency for the Tuscany runtime. I don't know if this was
intended. I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.
Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
environment...
What would be the granularity of these OSGi bundles? If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
a) Export more than we really believe is correct. This
leaves us in the current unsatisfactory position of exposing
unwanted implementation internals.
b) Combine multiple maven modules with a close implementation
affinity into a single OSGi bundle, and only expose true
APIs or SPIs from these bundles.
c) Refactor the code to remove dependencies on internals of other
modules, and create new SPIs or APIs when this isn't possible.
I believe a combination of b) and c) is the best approach.
We've already rehashed this (and disagreed on this) in several other
threads, where I've already given my opinion:
- 1 bundle per module
- clean API/SPI imports/exports
- Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
registry mechanism (what we have now in Tuscany or better a
combination of
what we have now and the Eclipse Equinox registry for example) to detect
which pieces are installed and activate their capabilities.
Can you say a bit more about what an "extension registry mechanism" would
look like?
What the tuscany-all/manifest jar are trying to do is to have users
not need
to know about the internal makeup of Tuscany. So they can simply use
tuscany-all and avoid needing to know about all the dozens of different
Tuscany modules and their dependencies, and that should keep working over
many Tuscany releases whereas as we keep adding/deleting/changing the
modules we keep breaking user builds for each Tuscany release if they
refer
to the individual modules. Maybe the granularity isn't quite right yet
and
we need something in between the all jar and all the individual modules.
Is there much agreement that avoiding users needing to know about the
internal Tuscany modules is a Good Thing?
Yes, I think this is important. Ideally the Tuscany core runtime
would figure out which pieces are needed for the domain configuration
and load these pieces automatically.
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)
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
- the launcher should detect the presence of installed extensions in a
particular Tuscany installation
- as a user / app developer I should not have to know the list of JARs
from all these extensions.
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).
[1] http://www.eclipse.org/equinox/
[2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/
-- Sebastien