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: <45641FFE.7070804@nada.kth.se>
Date: Wed, 22 Nov 2006 11:01:34 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: getting started with 2.2
References: <724FBE6DAE2F074A8CF33C6FB207C72C03B851@server2.SEI.local>
 <ejhbni$b17$1@sea.gmane.org> <455C6CC9.7000306@reverycodes.com>
 <422170EC-259D-47CD-981D-B3D94A3C2833@apache.org>
 <45622284.7070104@nada.kth.se>
 <01487F5F-EAE6-440E-914B-C98974D0D368@apache.org>
 <45633F26.3080801@nada.kth.se>
 <8a1369284352b8bd3d7c33e775a2a238@wrinkledog.com>
 <45635FE3.70001@nada.kth.se>
 <6cc46c7497bce320e1e8401920cf21bf@wrinkledog.com>
 <ea2e0fb9f19ed54bc24c6502f284a92a@wrinkledog.com>
 <45639830.6010905@nada.kth.se>
 <5435649532cc7504bd7e2f329d8cb5ea@wrinkledog.com>
In-Reply-To: <5435649532cc7504bd7e2f329d8cb5ea@wrinkledog.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Mark Lundquist skrev:
>
>
> On Nov 21, 2006, at 4:22 PM, Daniel Fagerstrom wrote:
>
>     To remove the use of the cocoon deployer you remove the following
>     snippet from the pom for cocoon-dist-samples:
>
>
> Right, yeah... I had just tried that, as a matter of fact, and... it 
> worked, and now I got samples! :-) :-)
>
> Thanks for all the help!
>
> I have a few questions... :-):
>
> 1) What does that Cocoon deployer do, anyway? Apparently (a) it's 
> required for shielded classloading, (b) which is currently broken, but 
> (c) if you built with shielded classloading turned off, you don't need 
> it, so (d) you can comment it out of the POM, because (e) it currently 
> breaks the packager. Anyway, it works without the deployer... why is 
> that?
Before, the deployer did a lot of work. Among other things it looked for 
Avalon and Spring configuration files and sample sitemap content and 
copied them to the right places in the webapp. Besides the work needed 
for using the shielding classloader. Recently we have moved most of what 
the deployer did to the startup part of Cocoon to make rapid development 
possible.

AFAIU the deployer currently only do the shielding stuff which is optional.

> 2) It appears that I'm building a war and then deploying it into 
> Jetty. I presume the packager built the war, and then the Jetty plugin 
> finds it and runs it? 
Actually the Jetty plugin doesn't use the war but the unpacked webapp.

> Is there a way to do this without a war, so that I can try out changes 
> to artifacts /in situ/ and not have to rebuild+restart.
This is what already happens.

The reason for the war packaging is that, IIUC, if the packaging type of 
the pom is war, the war plugin 
http://maven.apache.org/plugins/maven-war-plugin/ will be used and its 
war:war goal will be executed.

You can instead use "mvn war:exploded" to get rid of the war packaging 
stage and save some time during compilation.

If you develop with Eclipse you can use the Jetty plugin and point it 
directly to your webapp directory. In that case it is enough to use "mvn 
eclipse:eclipse" before importingh your project into Eclipse. After that 
you don't need to use Maven at all during development.

Also for development you should *not* start from the  
cocoon-dist-samples, that module is only intended for packaging a 
complete demo that you can run OTOB. It depends on, besides a number of 
blocks, the cocoon-webapp. So there is some copying of webapp resources 
involved that you don' want during development.

For development you should either start by creating your webapp with the 
Cocoon webapp Maven archetype 
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g1/1159.html. Or by 
copying cocoon-webapp. Then you add dependencies to the blocks that you 
want to use to the pom.

/Daniel