cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Roadmap for Cocoon Blocks
Date Wed, 12 Oct 2005 14:21:48 GMT
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, 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:, 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.


View raw message