cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Kernel integration in 2.2?
Date Mon, 29 Nov 2004 21:08:36 GMT
Reinhard Poetz wrote:
> 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

Only one thing is missing: you need a "linkrewriter" in place because 
one block does not now where the other block's URLs are mounted.


View raw message