Pier Fumagalli wrote:
On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote:
Pier Fumagalli wrote:
On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote:
Just one small nitpicking comment, we should say "3.0 will *most
probably* use OSGI" - as you said, it's a nice goal to have but I
don't think we're 100% positive on that yet, there are still a
few unknowns.
I agree wholeheartedly... I am not 100% sure that OSGI is the
perfect solution. AFAICS it's a little bit too cumbersome for my
brain.
And I know a lot of others share my concerns (from discussions at
the GT).
Any specific concerns about OSGi?
Personally, it looks "cumbersome" to me... Heck, I'm writing an
Eclipse plugin at the moment, and if it wasn't for the Eclipse Plugin
editor and stuff, I'd be totally lost.
OSGi gives us classloader isolation and the possibility of hot
plugabillity. Both are rather complex areas, and things that we require
from the real block system, so some extra complexity is hard to avoid.
An advantage of using OSGi instead of a home brewn solution is that we
don't have to solve all these complexity issues ourselves. As an example
there actually allready was an Eclipse plugin editor there that helped you.
Since the flow came along, I got quite lazy (weakly typed languages
rule) and the complexity of writing (and maintaining) a set of
metadata files related to each individual block, on top of sitemaps,
wirings, xconfs, source Java files and so on is definitely not
appealing to me.
For the Manifest.mf, the only complexity I have experienced is
maintaining the export and import of packages. There are several things
to say about that: First there are tool support to help you, Eclipse
e.g. There is also a tool for calculating dependencies between the
bundles: http://oscar-osgi.sourceforge.net/mangen/, that we maybe could
use in our build process. You can also simplify export and import rules
by using wildcards.
But IMO there is a more important aspect of imports and exports: they
declare what your bundle export and import and if they are complicated,
that often mean that your bundle doesn't have a focused concern area and
that its interface to the rest of the world is fat. This leads to rigid
systems that are hard to reuse. So it is true that the current
"bundleization" of Cocoon have complicated export and import section. I
don't see that as a problem with OSGi, but rather as a consequnce of
what we all allready know: Cocoon is monolothic, have far to much inter
dependencies and fat interfaces and it is not that well defined what sub
parts there are.
As soon as the basic mechanisms are in place I and hopefully others will
focus on geting the contracts leaner.
I'm wondering if there isn't an easier (simpler) way to approach the
problem.
Sure, don't we all ;) We can of course wait for ever on the perfect
approach for real block. But after having waited for the for 3+ years, I
and some others wanted something good enough now rather than something
perfect in the future.
For your core, you might remeber that I supported that we should use it
and wanted to start working on it, but you never found time to answer my
qustions about some of the concepts in it or commit the much improved
version of it that you said that you had.
I really liked the idea of POJOs, and now OSGI forces me back to
re-use service factories again (so, what's the difference from
Avalon???), and on top of what Avalon does, it introduces all those
manifests and stuff...
At the CocoonGT one year ago the concensus was to use two level of
containers for blocks one, intra block container like ECM++ or Spring
that keeps back compability and give convenient component handling and
one inter block container taking care of class loader isolation and hot
plugabillity. OSGi have what is needed for the second part, but is as
you notice not as convenient as e.g. Spring for the internal component
management. The style of OSGi is rather similar to Avalon but as
allready said it have classloader isolation and hot plugability support
and above that it is standardized. So we can be rather confident that
there is not going to be any Avalon community kind of things.
Oh, and please don't tell me that I can still use Avalon, Spring or
whatever in the new thing.
Why shouldn't I? That was a major design criteria that we should keep
back compability.
If we go down the OSGI route, I'll code for OSGI, not for some
pseudo-adapter of some sort... I'm not one to take shortcuts.
I can agree with that attitude, even if I think most users will be quite
happy to be able to use their favorit component container.
OSGi is rather low level for component management, only the basic
mechanisms are there (+ classloader isolation and hot plugabillity
support, which is what makes it unique), but no one stops you from
building more convenient abstractions above that.
In R4 there is a declarative service specification, that allow for much
higher level specification of components.
Also Niclas Hedman have moved his post Merlin/Metro work to use context
dependency injection and it is built uppon OSGi, maybe he can comment on
it. There have also been other work in the OSGi community on higher
level component handling, the declarative service specification is based
on some of those experiences.
/Daniel
