cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Date Mon, 05 Sep 2005 14:38:44 GMT
Daniel Fagerstrom wrote:
> 
> At least for OSGi R3, each block (bundle) must export a unique set of 
> packages. It would be nice if we could move all classes and interfaces 
> so this is the case and deprecate the block classes and interface with 
> non unique packages before we release 2.2.0 final. It is not particulary 
> complicated but requires some work.
> 
> It is necessary (if it hasn't changed in R4), that we move to block 
> unique package names before we start to release OSGi functionality. So 
> the sooner we can deprecate the non unique package use, the better. But 
> it is not a blocker for 2.2.
> 
I think someone mentioned that R4 does not require the unique package
names anymore. hmm, but I'm not sure.

> It is not necessary to split into api and implementation for introducing 
> OSGi, but it will certainly be easier to use, and scale much better if 
> we do it. Especially when there are several blocks implementing the same 
> api, it will simplify things if we have separate api blocks. Then the 
> api blocks that a block depends on can be downloaded during compilation 
> of the block, and the user can choose between several implementaions of 
> the used apis while deployoing the block.
> 
Yepp.

> Spliting the code into api and implemetation require however 
> considerable work and thought as not everything is designed with such a 
> split in mind. So I think that is something that we need to work on 
> incrementally.
> 
Agreed.

>                                      --- o0o ---
> 
> Considering what we need to _change_ to get real blocks: The only thing 
> I know about is some package renaming as discussed above. It will be 
> more about _adding_ things. We will need manifest files with OSGi info 
> in and we will need block.xml that describe dependencies on other blocks 
> and bundles (this need to be integrated with the m2 dependecy 
> information). The block.xml will also contain references to the blocks 
> (sample) sitemap and component configuration(s) as we discussed last 
> weak. This is all things that we can work on in an evolutionary way.
> 
>  From my current knowledge the largest remaining question is about how 
> to configure components that a block exposes. Part of it is clear, the 
> block.xml can refer to the .xconf(s) that is part of the block today and 
> export the components within the configuration so that it is available 
> to other blocks (through OSGi services as discussed earlier). This far 
> everything is as before, but done using OSGi instead of using compile 
> time mechanism.
> 
> The question is how a user should be able to adapt the configuration of 
> the components of the block while using it. Today one can modify the 
> component configuration snippets by hand, but that is not as easy while 
> using blocks as the configuration will be embeded in a precompiled block 
> that is packaged as a bundle and asumed to be used as is. One possible 
> solution is to decide before hand what should be deploy time 
> configurable and use block attributes for this (BTW block attributes and 
> the setting stuff that Carsten and Ralph are discussing seem to have a 
> lot in common, we should see if the block attributes could be build 
> avbove or integrated with the settings stuff). Another solution is to 
> export the implementation of the components and configure them in the 
> block that uses them instead (don't like this though, as it don't give 
> any isolation). A third solution could maybe be to declare the 
> configuration as a "fragment" that can be overided. Fragments is an 
> Eclipse concept that have been made part of OSGi R4, I don't know enough 
> about it to say if it is usefull in this context. Other ideas?
> 
I think one of the main problems is that you never know what
configuration a component uses/requires. So I think we need a formal
description for each configurable component, like a schema or something.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message