Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <440D801D.2030905@apache.org>
Date: Tue, 07 Mar 2006 13:44:13 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Status of block development
References: <440C58D2.40008@apache.org> <20060307084721.GB3463@vision.anyware>
In-Reply-To: <20060307084721.GB3463@vision.anyware>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jean-Baptiste Quenot wrote:
> * Reinhard Poetz:

>> - [cocoon-deployer-webapp-sample] is a very simple example. Here we need
>>   something more useful. We have to identify blocks that we want
>>   to show. I suggest
>>   # cforms + samples
>>   # ctemplate + samples
>>   # auth + samples
>>   # session-fw + samples
> 
> 
> Don't you think we should provide all stable and not deprecated blocks?

yes, but IMO not in the first run. We only have very little experience with the 
complete blocks idea and therefore we should work incrementally. (e.g. if the 
block.xml is changing, you have to update it for *all* blocks and it's a 
difference if you do it for a handful or for 100+ files)

>>   Except cforms all these blocks are not shared between 2.1 and changing
>>   cforms shouldn't be a big problem as the cforms directories are
>>   references from 2.1 on a very detailed level. Right?
> 
> 
> Can you elaborate what changes are required for CForms?

The directory structure of blocks is different. See 
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo/src/ 
   which already uses the new one. In the archives you find some threads about 
the reasons that led to it.

> 
>>* I introduced the new Maven goals
>>  - cocoon:deploy and
>>  - cocoon:deploy-war
>>
>>Both are based on the Maven war plugin. A demo can be found in [cocoon-deployer-webapp-sample]. As you can see, 
>>deployment is based on cocoon-deploy.xml. This file describes which blocks you want to deploy and how they are 
>>configured. These blocks are deployed to the webapplication.
> 
> 
> What (or where) is the schema of this file?  

http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-core/src/main/resources/xsd/deploy-schema-1.0.xsd


> What component is
> using this file?  

the block-deployer 
(http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer)

> Why is there redundancy with pom.xml, both are
> referencing cocoon-default.  What is cocoon-default?

pom.xml describes which artifacts are required to build a project. The 
difference is, that block.xml describes which requirements in the form of other 
blocks a block has but *doesn't* say anything about conrecte implementations.

In cocoon-deploy.xml you can define which _concrete_ blocks that *you* in the 
role of the deployer want to use to satisfy a requirement.

ad cocoon-default: this is a collection of blocks that are necessary to get a 
minimal Cocoon. As this will be under heavy refactoring for some time (e.g. 
cocoon-core will be split up in more parts), I introduced this module to make 
the dependencies of depending blocks more stable.

> When I � mvn install � i
> cocoon-block-deployer/cocoon-deployer-webapp-sample, the generated
> webapp in target/demo does not contain sitemaps and other
> resources, only web.xml and jars, am I missing something?

No :-)
Have a look into WEB-INF/web.xml. It uses the BlocksManager as servlet, or IOW 
as entry point into the Cocoon world. The BlocksManager sets up Cocoon by using 
all the deployed blocks. The sitemaps that you're missing can be found in the 
block directories (/blocks/[block]/COB-INF/sitemap.xmap). There is no such a 
thing as a root sitemap anymore.

The configuration file of the BlocksManager is /WEB-INF/wiring.xml. It is 
generated by the block deployer and contains all deployed blocks. A sitemap 
block (= a block that has a COB-INF directory and a sitemap) can be mounted to 
the managed URI-space. If a request hits the servlet (BlocksManager), it looks 
first if a block is mounted to the requested path and if yes, it delegates 
processing to the block's controller (currently we only have the sitemap as 
implementation, but here we have room for other ways)

>>Before block deployment, the normal web app creation of the war plugin takes place which mainly consists of copying 
>>files from src/main/webapp to target/[finalName].
> 
> How to achieve this step?  It seems it is not done automatically.

hmm, it works for me. The plugin would copy any content from within 
./src/main/webapp to ./target/demo but ATM the only file that is copied is 
web.xml (from ./src/main/webapp/WEB-INF/web.xml).

I did

mvn clean cocoon:deploy jetty6:run

and then I entered

http://localhost:8888/p1/test and
http://localhost:8888/p2/test

If I find some time today, I will extend the sample webapp by some more blocks.

-- 
Reinhard P�tz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de