cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sun, 14 Sep 2003 21:15:10 GMT

On Sunday, Sep 14, 2003, at 20:51 Europe/Rome, Vadim Gritsenko wrote:

> Stefano Mazzocchi wrote:
>
>>
>> On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:
>>
>>>> if you wish to have proper names, that would be a comman line 
>>>> property away. This, for example, is useful for those projects that 
>>>> might wish to still distribute a complete war (forrest comes to 
>>>> mind) where the wiring.xml file is generated at build time.
>>>
>>>
>>> So the answer will be then: those directories are generated during 
>>> build time.
>>
>>
>> It is entirely possible to create a build process that creates the 
>> wiring.xml file without using the block deploying tool. I think 
>> cocoon apps like Forrest/Lenya might want to choose two types of 
>> distribution: a big war with all the blocks pre-expanded and the 
>> wiring.xml generated at build time and another one as blocks to be 
>> deployed on top of an existing cocoon.
>
>
> But would it be possible to provide big war with blocks not-expanded 
> in the predefined directory [1] and with no wiring.xml generated and 
> have deployer work it's magic?

why? isn't it easier to provide a wiring.xml already built?

> Once such war is deployed, blocks unpacked and wiring xml generated 
> (possibly with human intervention as you mentioned below) by the 
> deployer tool, you get to the point were you can just zip everything 
> up again and have "a big war with all the blocks pre-expanded and the 
> wiring.xml generated".

the deployer tool is not something that is run when the war is expanded 
and is *NOT* something that cocoon should have access to (at least, in 
its default CLI incarnation) [mainly for security reasons]

>>> We can either provide block deploy directory which will not be 
>>> dependent on container behavior (like we allow specifying work 
>>> directory in web.xml), or provide block temp directory.
>>
>>
>> well, which is what we do with WEB-INF/blocks/, don't we?
>
>
> Which brings us to square one: what will then be the directory (marked 
> with [1]) for the not-expanded blocks? Is it the same directory or is 
> it different directory?

My point is: there is no need for non-expanded blocks to be held on 
disk.

BTW, I have the impression I'm not understanding what you are aiming 
at. Instead of discussing the solution, can you point out the problems 
you see first? I think that would help me understand because at the 
moment, I'm not sure I do.

--
Stefano.


Mime
View raw message