You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/11/29 19:37:19 UTC
Kernel integration in 2.2?
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 http://wiki.apache.org/cocoon/22BlockImplementation
--> 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
--
Reinhard
Re: Kernel integration in 2.2?
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> 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.
Thanks. Added to the Wiki page.
--
Reinhard
Re: Kernel integration in 2.2?
Posted by Stefano Mazzocchi <st...@apache.org>.
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 http://wiki.apache.org/cocoon/22BlockImplementation
> --> 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.
--
Stefano.