From dev-return-47747-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Sun Sep 14 18:52:05 2003
Return-Path:
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 11113 invoked from network); 14 Sep 2003 18:52:04 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
by minotaur-2.apache.org with SMTP; 14 Sep 2003 18:52:04 -0000
Received: (qmail 79391 invoked by uid 500); 14 Sep 2003 18:51:52 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 79014 invoked by uid 500); 14 Sep 2003 18:51:50 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
list-post:
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 79000 invoked from network); 14 Sep 2003 18:51:50 -0000
Received: from unknown (HELO out005.verizon.net) (206.46.170.143)
by daedalus.apache.org with SMTP; 14 Sep 2003 18:51:50 -0000
Received: from verizon.net ([138.88.145.181]) by out005.verizon.net
(InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP
id <20030914185154.TBLM15786.out005.verizon.net@verizon.net>
for ; Sun, 14 Sep 2003 13:51:54 -0500
Message-ID: <3F64B8C7.1090703@verizon.net>
Date: Sun, 14 Sep 2003 14:51:51 -0400
From: Vadim Gritsenko
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Implementing Cocoon Blocks
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [138.88.145.181] at Sun, 14 Sep 2003 13:51:54 -0500
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N
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