cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Update of "Blockathon2005Report" by BertrandDelacretaz
Date Tue, 19 Jul 2005 16:32:55 GMT
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.

Mime
View raw message