Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 3293 invoked from network); 4 Nov 2006 18:37:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Nov 2006 18:37:00 -0000 Received: (qmail 53789 invoked by uid 500); 4 Nov 2006 18:37:10 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 53327 invoked by uid 500); 4 Nov 2006 18:37:08 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 53316 invoked by uid 99); 4 Nov 2006 18:37:08 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO [127.0.0.1]) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Nov 2006 10:37:08 -0800 Message-ID: <454CDDBF.70207@apache.org> Date: Sat, 04 Nov 2006 19:36:47 +0100 From: Carsten Ziegeler User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [2.2] Runtime deployment References: <454BBFE7.5030809@apache.org> <454C6B85.50804@mobilebox.pl> In-Reply-To: <454C6B85.50804@mobilebox.pl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Leszek Gawron wrote: >> What is missing? >> 1. With the changes from above, Cocoon does not run as an unexpanded war >> file anymore. So I think we should extract the COB-INF directory into >> the temporary directory and mount the blocks from there. This should be >> very simple to change. > > apart from one thing, how do I do that?: >> >> >> >> >> >> >> >> >> > > when I get block files unpacked to some temporary directory which > location can change any time. > We could provide our own protocol "temp:" which is resolved to the temporary directory, so you can use "temp://blocks/geminismart-server-mobile/" for example. >> 2. We should check on startup if we need to extract a COB-INF directory >> again. If anyone has a good idea how to check this without too much work >> would be great. > > wouldn't it be sufficient if we checked for blocks/block-name directory > existence? Hm, it depends - this assumes that an artifact during development never changes. But for example if you're using "1.0-SNAPSHOT" the content will change during development but the block-name will not. My first idea was to put the jar size in the temp directory as well and only extract if the size has changed. (I'm not sure if the size is a reachable information though). Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/