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.
