Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43031F85.70207@mobilebox.pl>
Date: Wed, 17 Aug 2005 13:29:09 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [Proposal] Switch to Maven NOW
References: <43031AFF.4010507@apache.org>
In-Reply-To: <43031AFF.4010507@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:
> Actually I'm a little bit tired of the ongoing Maven discussion.
> Why can't we just switch the trunk to Maven NOW? Who really cares if
> trunk is not buildable/working for the next days until the switch is
> finished?
> 
> So I propose to:
> - Completly remove the lib directory
> - Create a sub project core in the trunk directory
>   I think we will use several (sub) projects, one for the core,
>   one for the webapp etc. and use Mavens multiproject feature.
> - Move src/java to core/src/java
> - Create a Maven project description with all dependencies for core
+1

> Et voila, we will get a cocoon.jar hopefully.
> Then we create a webapp subproject, move the webapp there and build
> a webapp with just the core.
> 
> And then we continue from there, moving test, moving samples etc.
> On thing at a time. And we can always ask the maven guys for assistence
> and hints.
> 
> Ah, and finally, I think we should start right away with m2.
+1

Several things that should be taken into account IMO:

I am not following OSGi threads lately (total lack of time) so I do not 
know the final block packaging format but I'd love to see it as single 
artifact. I have already tried to use maven for my cocoon based project 
mainly because of the fact that currently even the simplest block is:
- a jar file
- xconf files
- xlog files
So you cannot just put the block binaries into maven repository.

other example that I posted some time ago: if every cocoon uses 
error2html.xsl by default (along with some other default resources) they 
should be also packed into jars.

Next one: we should resign from using xpatch (apart from web.xml maybe). 
With single cocoon.xconf it was bearable. With current functionality 
that allows xconfs to span accros multiple files it just got harder. Try 
to keep your xconf files intact and add some definitions at build time for:
- cron triggers
- cforms definitions
you'll know what I mean.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65