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 Tue, 11 Oct 2005 14:02:30 GMT
Jorg Heymans wrote:

>3.0 is a different beast alltogether. Likely we will need an m2 plugin
>that can compile one block against other blocks using osgi dependency
>rules (ie using the manifest information). The same goes for dependency
>resolution, as it needs to be made osgi aware (right Daniel?).
>So unless he knows a lot about osgi, a block developer will have to use
>our m2 deployment framework to target 3.0.
>Or am I seeing this m2-osgi build and deploy time integration too
>complicated for what it really is ?
As long as the build of a bundle only depends on explicit jars and not 
on other bundles, the build is rather simple. This will be the case in 
our initial work with OSGi as we work more on bundelizing the existing 
Cocoon than integrating with external bundles. And for our own blocks we 
need to take care of the dependendency on libraries anyway.

As soon as we want to have the build dependent on other bundles it 
becomes a little bit more complicated as the build system must be OSGi 
aware to know what packages in a bundle that will be available for 
another bundle.

Now, even if this happen to be somewhat complex, it probably doesn't 
need to be a problem for us. Eclipse have allready solved this in theire 
build system and created external APIs for handling dependency 
information. I have discussed this question a little bit at the Felix 
list, and some of the main developers of the Eclipse kernel suggested to 
use the Eclipse mechanism and seemed to be willing to help making it work.

So for the nearest future it will be enough with a rather simple system, 
like the M2 OSGi plugin at Felix. And when we require a more 
sophisticated solution, we have a quite clear idea about how to solve that.


View raw message