cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sun, 14 Sep 2003 18:51:51 GMT
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?

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 first distribution is for those who don't have a cocoon already 
> installed, the second will be for those who do.
>
>>  Is there a way to drop in block into expanded war and have block 
>> deployer pick it up?
>
>
> It could be possible, but only if there is no polymorphic behavior 
> associated to the dependencies of that block. Otherwise, human 
> intervention to choose which block implementation would implement the 
> required block behavior cannot be avoided.
>
>> Deployer will have to then pick up block from some directory, 
>> generate 123456789 directory, and unpack block there, all in runtime, 
>> after the build time.
>
>
> This is entirely possible, but, as I said, only if there is no need 
> for human choices which are:
>
>  1) polymorphic implementation choice
>  2) deploy-time configuration
>
> The process can be automated, but not as much as for WARs because WARs 
> are much less capable than blocks.
>
>>>>> Unpacked blocks:
>>>>> Good question -- maybe in WEB-INF/blocks ?
>>>>
>>>>
>>>>
>>>> I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
>>>> them into $temp/blocks, where $temp is temporary directory 
>>>> configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to 
>>>> point out to blocks which are located outside of the blocks 
>>>> directory, for development needs.
>>>
>>>
>>>
>>> that might be a solution, but would force us to consider blocks 
>>> "read-only" because, otherwise, if a block writes something on its 
>>> internal file system, that content is not guaranteed to be >> 
>>> persistent.
>>
>>
>>
>> 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?

Vadim



Mime
View raw message