Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <454CEDB4.6070303@nada.kth.se>
Date: Sat, 04 Nov 2006 20:44:52 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
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>
 <454CDDBF.70207@apache.org>
In-Reply-To: <454CDDBF.70207@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler skrev:
> 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?:
>>> <map:match pattern="mobile/**">
>>>     <map:mount uri-prefix="mobile" src="blocks/geminismart-server-mobile/"/>
>>> </map:match>
>>> <map:match pattern="central/**">
>>>     <map:mount uri-prefix="central" src="blocks/geminismart-server-central/"/>
>>> </map:match>
>>> <map:match pattern="**">
>>>     <map:mount uri-prefix="" src="blocks/mobilebox-webapp-commons/"/>
>>> </map:match>
>> 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.

I would prefer blockcontext:/geminismart-server-mobile/ or 
blockcontext:geminismart-server-mobile/ as the COB-INF directory in a 
block has the same role as a resource directory as the top level 
directory for a webapp.

An open question is how to find the block name. I doubt that version 
numbering is systematic enough to make it possible to strip it away from 
the block name for the file name of the block jar.

We could use the artifactId from the 
META-INF/maven/org.apache.cocoon/cocoon-block-name/pom.properties file.

Maven also sometimes (?) creates some field in the manifest file that 
could be used e.g.:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: maven
Build-Jdk: 1.4.2_06
Extension-Name: cocoon-batik-impl
Specification-Title:
Specification-Vendor: The Apache Software Foundation
Implementation-Vendor: The Apache Software Foundation
Implementation-Title: cocoon-batik-impl
Implementation-Version: 1.0.0-SNAPSHOT

I doesn't create such manifest files all the time though. The jars 
created when I compile locally with Maven 2.0.4 looks like:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: Daniel Fagerstrom
Build-Jdk: 1.5.0_06

One possibility would to have a block specific manifest entry with the 
block name:

Cocoon-Block-Name: cocoon-batik-impl

/Daniel