cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Roadmap for Cocoon Blocks
Date Wed, 12 Oct 2005 16:50:44 GMT
On Wednesday 12 October 2005 22:21, Daniel Fagerstrom wrote:
> 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.

Not much to report in this ContextIoC [1] area. I have been busy porting 
Merlin/Metro to a OSGi bundle, where the Merlin/Metro services are seen by 
other bundles, and the Merlin/Metro services can use the OSGi services. And 
some stuff around all to make this work. All needed as migration path for the 
project I am involved.

Other than that, most important observation in the OSGi adventure is probably 
that bundles becomes "just nice size" (or maybe it is just my preference). 
Not too large that 100s of classes needs to interact with each other with 
heaps of GoF patterns required to hold everything together, and essentially I 
don't feel I need any "component framework" at all. A dozen or two classes is 
typical bundle size for me, and all bundles that provides a service generates 
two Jars, one with the API and one for the impl, so the API can be placed in 
dependent bundles, as originally intended.
That allows me to "fabricate" the needed components or their factories in the 
Activator, pass it down the line with constructor injection, and pretty set 
to go. I.e. I am on the same page as Pier when it comes to "I don't like 
complex solutions", and to me Spring is complex, Pico is complex, yes 
Merlin/Metro is complex. One gets sucked in slowly into these platforms, but 
end up fighting different kind of battles (XML hell) instead of coding Java. 

With the "Feature" feature in OSGi R4, where sets of bundles are treated as 
mega-bundles, I think my "small bundle approach" makes very good sense, and a 
component-like organization is emerging.

I still think that OSGi needs better implementations of many presecribed 
services, i.e Config, Prefs, Meta, User, Permission and so on services. I was 
hoping that Felix would become the place where those implementations 
flourished and could be shared across half a dozen projects at ASF alone.

As for Cocoon to use OSGi, I am not familiar enough with the inner workings of 
Cocoon of today to have any clue of how hard that would be to remain 
compatible with previous versions. I guess that 100% compatibility is 
impossible, by the fact that there are no well-defined contracts, and any 
user could be using any internal bits that it happens to reach one way or the 
I hope the Cocooners can work all of this out, as the motivation for me to use 
Cocoon diminishes by the days, as it gets easier and easier to do stuff in 
competing platforms that only made sense in Cocoon previously.



View raw message