Mike Edwards wrote:
...
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.
I'm aiming for a small number of packages, similar to the Eclipse
distributions that people build (a Java developer distro, a Web
developer distro, an Enterprise distro, a Mobile device distro etc) to
not have to worry about the bits and pieces. We already had that
discussion in January and IIRC I had also brought up the similarity
with Eclipse distros then :)
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!)
Yes, but I'm not sure we're a long way from that today, except for the
few cases where people have gone around SPIs. OSGi imports/exports will
help prevent that, as going around exported SPIs will break the build.
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.
Exactly!
- 1 bundle per module
- n bundles per 'bigger packaging' distro
Good debate here, but let's be clear about the big picture before the
details swamp the debate.
:)
--
Jean-Sebastien
