cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Date Mon, 05 Sep 2005 13:33:07 GMT
Carsten Ziegeler wrote:

>Ralph Goers wrote:
>>>How much do we know about the directory structure required by Maven? I 
>>>know that OSGi R3 requires a directory structure, R4 doesn't.
Don't understand the comment (from Upayavira) about directory structure, 
R3 and R4, care to explain?

>>>one package per bundle would make implementation much easier.
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.

>>Unfortunately, my knowledge only extends to Maven 1.  Carsten would have 
>>to answer this as he has been working on the conversion to Maven 2.  It 
>>doesn't look like he has had to do much so far, but I'm still worried 
>>that circular dependencies between blocks are going to show up.
>Currently we don't have circular dependencies, so the current structure
>will work with maven as well. Now m1 and m2 do not differ that much when
>it comes to the directory structure: one java source directory per
>project, several resource directories (if you need), on directory for
>java tests etc. So this works pretty well for our current blocks.
>If we want to split blocks into api and impl for example, we have to
>create two maven projects - this of course then will also reduce
>problems with circular dependencies.
>I don't know if we need something else for osgi, but I think this
>approach (api vs impl) should work there as well.
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.

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 

>>>I just want to avoid any "we can't release X because we're waiting for 
>>>feature Y", that is something we've stumbled with all too often.

We should get into the habit of releasing what we actually have done 
rather, than not releasing because we developed something else than what 
we planned.

>>Yes, I would like to avoid that as well.  However, I don't know that we 
>>need to be using a formally released Maven 2 to know how to do this.
>I think time will tell. Switching to maven is currently at a very low
>rate, not many of us are working on it (which is ok of course), the same
>happens to the OSGi stuff. We shouldn't delay 2.2 neither because of
>waiting for m2 nor waiting for OSGi. The current version seems to work
>and build system works as well.

                                     --- 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?


View raw message