cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Kernel integration in 2.2?
Date Mon, 29 Nov 2004 18:37:19 GMT
Pier Fumagalli wrote:
> On 29 Nov 2004, at 17:32, Reinhard Poetz wrote:
>> Pier Fumagalli wrote:
>>> On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
>>>> Pier,
>>>> IIUC a block declares in a descriptor file all components that it 
>>>> wants to provide to other blocks by their interfaces. External 
>>>> blocks can then lookup those components because they are provided by 
>>>> the classloader.
>>>> Is it still true that a block can have a "block-public.jar" and a 
>>>> "block-private.jar"? The block-private.jar is shielded and only 
>>>> available within the block and the block-public.jar contains all 
>>>> classes (including the interfaces of publicly available components + 
>>>> other public available classes) that will be publicly available?
>>>> I'm  asking because the whiteboard/block-builder is based on a 
>>>> separation of public and private classes (--> JARs). This ensures 
>>>> that block A, that depends on block B, is compiled only by using 
>>>> block B's public JAR. (... and the eclipse .classpath also contains 
>>>> only block B's public JAR).
>>> Sorry, been on holiday for the last couple of weeks...
>>> No, in the new version of the kernel, all JARs are "public"... I 
>>> simply noticed that "private" classes to a block were becoming (after 
>>> writing 20 or so blocks) a major pain in the a**... And at the end of 
>>> the day, I found them quite counterproductive.
>>> Developing I found myself in the position of moving classes from 
>>> "private" to "public" when extending blocks, and ending up with 
>>> having nothing private and everything public most of the times...
>>> So, to keep the story short, no, there's no more difference, 
>>> everything is public.
>>> There is (though) an implied "local.jar" that doesn't need to be 
>>> declared in the deployment descriptor but is simply a jar file that 
>>> (if it exists) gets loaded... Look at the build script, it'll create 
>>> this jar for each block containing sources and the kernel will use it 
>>> even if not declared...
>>>     Pier
>> Thank you.
>> Yesterday, Sylvain and I talked on ICQ about block implementation but 
>> without considering requirements coming from the kernel 
>> implementation. I summarized it and will put it into our wiki as soon 
>> as it is finished.
> Thanks,
>     as I said, I've been on holiday for 2 weeks (Egypt, no internet 
> access) and I'm having a hard time catching up... Any summary will be 
> good cuz I'm running through thousands of emails in one go and the brain 
> is bubbling away! :-P
>     Pier

find the summary at
--> any feedback would be *very* appreciated to get a clear todo list on what we 
have to change/implement at the existing  Cocoon core implementation in trunk


View raw message