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.
/Daniel
