Info and reports about the ApacheCon 2005 \[Blockathon\]. |
See also osgi.
The template block has been hacked by Reinhard to work as an OSGI bundle, and Sylvain has been working on a component to bridge the OSGI and ECM++ component managers. Stay tuned...
Block metadata information will be used for the following purposes:
We have discussed several options for generating this metadata, and using our own block.xml seems to be the safest option for now. The other "views" on this metadata will be generated a build time.
It seems to make sense to repackage external jars (xalan, fop, for example) as individual OSGI bundles, based on the dependencies discovered at build time.
The cleanest solution seems to be the downloading of these external jars from existing repositories (ibiblio), using the appropriate ant tasks.
The downloaded jars will then be packaged as OSGI bundles for deployment, maybe exporting all the packages that they contain be default.
When compiling a bundle, there must be a way to get access to interfaces defined in other bundles that we depend on.
The brute force solution that comes to mind is:
But there is probably a better way, or existing tools in the OSGI projects.
We should create individual bundles for groups of interfaces that represent contracts between the Cocoon core and the blocks.
To develop a sitemap block, for example, one should be able to take a single bundle containing the relevant interfaces, and only these (and the relevant documentation, see below).
The OSGI spec provides for documentation in the OSGI-OPT directory of a bundle, this would be a nice way of making the bundles/blocks standalone components.
Agreement on a list of high-level goals which are independent from OSGI.
Posted to the dev@ list, see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112177131522853&w=2
(the crossed out "immediate benefits" don't mean there are no immediate benefits - we crossed this section out thinking that the benefits are evident, and we wanted to have lunch at that point
Talk about blocks management led by Daniel.
The OSGI mechanisms for import/export of classes are based on package names, a bundle must export a complete package, it cannot export a single class.
This means we have a problem with our current package names, for example many blocks have classes in o.a.c.generation or o.a.c.transformation, that need to be exported. The package names will need to be changed, for example to o.a.c.blocks.html.HtmlTransformer.
Existing blocks using the ECM++ component manager internally will need to make their services available to the OSGI framework. This can be done when the ECM component manager is being setup, maybe by creating an ECM event listener which "relays" service availability info to OSGI.
We might want to make only some ECM components available as OSGI services.
Scenario:
As several blocks will be using ECM++ it makes sense to have an ECM++ bundle to make this shared code available.
In the same way, blocks using Spring, hivemind or whatever other component manager can make some of their components available as OSGI services.
The same pattern (component manager initialization - service instantiation listener - OSGI service registration) seems to be applicable in these cases.
The Cocoon trunk is running under OSGI! See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112170290723962&w=2
On the picture you see Reinhard in front and Daniel behind him - these guys have been making it happen this afternoon!
Daniel talks about the current state and next steps.
In the meantime, Sylvain is finishing the first release of Lepido to showcase it during Gianugo's Cocoon tutorial
The whiteboard/osgi code is being integrated into the trunk, to make it more convenient to work on.
Currently the OSGI-related code consists of three bundles:
The cocoon bundle:
The webapp bundle:
The cocoon-servlet bundle:
When loaded:
Main TODOs: