Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <452695D6.7060908@apache.org>
Date: Fri, 06 Oct 2006 19:43:50 +0200
From: Leszek Gawron <lgawron@apache.org>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: svn commit: r453534 -
 /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
References: <20061006090632.912FE1A981A@eris.apache.org>
 <4526353A.1090300@mobilebox.pl> <4526376C.4090201@mobilebox.pl>
 <4526467E.6060309@apache.org> <45265497.402@mobilebox.pl>
 <452660E1.9060303@apache.org>
In-Reply-To: <452660E1.9060303@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>>> Hmm, that's bad - I don't see a solution for this now. But we discussed
>>> at the GT an alternative handling of our blocks which would make the
>>> cocoon:deploy plugin obsolete.
>> which is ?
> :)
> 
> Currently the deployer extracts the files from COB-INF and META-INF into
> the file system (into the web application). We talked about skipping
> this step and adding a mechanism to the core of Cocoon which allows to
> access the information from within the jar without extracting it.
> This should be doable by using the class loader and some detection
> mechanism and avoids the deployer plugin. And more important it means

Seems like cocoon solutions are always a step ahead my comprehension. Is 
this really feasible?

-- 
Leszek Gawron
lgawron@apache.org