cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Roadmap for Cocoon Blocks
Date Wed, 12 Oct 2005 12:58:03 GMT
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.

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.

I'm wondering if there isn't an easier (simpler) way to approach the  
problem. 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...

Oh, and please don't tell me that I can still use Avalon, Spring or  
whatever in the new thing.  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.

     Pier


Mime
View raw message