Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.
The following page has been changed by BertrandDelacretaz: http://wiki.apache.org/cocoon/Blockathon2005Report The comment on the change is: Tuesday 19th afternoon info added ------------------------------------------------------------------------------ Info and reports about the Apache``Con 2005 [Blockathon]. - See also OsgiTipsAndTricks. + See also ["osgi"]. + + = Tuesday, June 19th, afternoon = + + == Role of block.xml == + Block metadata information will be used for the following purposes: + * Manifest information, when creating bundles + * Block build scripts for ant, Maven, Eclipse, IDEA, etc. + * Inclusion in gump.xml + * Deployement process: dependency resolution, wiring information + + 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. + + == Repackaging of external jars as OSGI bundles == + 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. + + == Compile-time access to interfaces defined in bundles == + 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: + * Download the bundle + * Explode the bundle jar and all jars that are found in it + * Delete all resulting class files, except the ones that the bundle exports + * Put all the remaining files in the classpath + + But there is probably a better way, or existing tools in the OSGI projects. + + == Interface bundles == + 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). + + == Documentation in bundles == + 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. = Tuesday July 19th, noon = Agreement on a list of high-level goals which are independent from OSGI.
