Jean-Sebastien Delfino 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 :)
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.
- 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.
Are people interested in exploring these ideas?
Jean-Sebastien,
I'll start with the last question first: YES.
But I'd next like to step back from what I can see is developing into a somewhat "active" debate (to
use a neutral euphemism) and investigate the big picture here.
Let me try to understand the motivations (yes, plural, I think) for multiple binary distro zips of
Tuscany. My initial reaction to seeing a list like the one above is "hmm - complexity - for the end
user" - they now have to understand which of those packages they need and install each of them
separately. The more packages, the more complexity.
Now, this is only looking at one side of things - why is splitting things into packages like that a
good idea? Well, I suppose there is the question of download size and size on disk. More packages
= each package can be smaller. You get what you ask for. The other side is smaller runtime size -
no unnecessary things get loaded.
For the download size, I see the merits of bacon slicing into sets of independent packages. For the
runtime size, other methods (eg lazy loading) might be an alternative.
I can see the argument to use an install system like Eclipse, but on the other hand, as a user of
Eclipse, I have to say that this aspect is one of the less satisfactory parts of Eclipse, and it can
be frustratingly hard to know that you've got the right set of stuff installed. Part of this is
about the number of packages and the set of valid combinations. If it's a small number then OK,
perhaps not a problem. Once the number grows, I think it does become a problem for the end user.
The question of the approach to OSGi is perhaps different. I think it does make sense to create a
bundle-per-module. It does make sense to have clean interfaces for each module with crisp lists of
imports and exports. (and yes, I know that we are a long way from that today!)
But I don't expect that OSGi bundles should be directly reflected into the bigger scale packaging.
In other words, the bigger scale packaging is aimed at satisfying the user's needs and a big package
could have 10 or 100 module-sized bundles in it, as necessary. That depends on overall function,
not on details of the modules used to provide that function.
Good debate here, but let's be clear about the big picture before the details
swamp the debate.
Yours, Mike.
