Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4545D00E.1000709@apache.org>
Date: Mon, 30 Oct 2006 11:12:30 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Deployment and the maven plugin
References: <4545BAEC.2070902@apache.org>
In-Reply-To: <4545BAEC.2070902@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Carsten Ziegeler wrote:
> The current version of trunk is feature complete; we only have one item
> left which we discussed briefly at the GetTogether and a little bit more
> in the past weeks in this mailing list: removing the need of the maven
> deploy plugin.
> There is one major advantage: make the use of maven 2 for building own
> projects optional. Currently, if you're developing your own Cocoon 2.2
> based project, you depend on the specific artifacts (jar files) which
> you can get from the repository *and* you need the maven 2 deployer
> plugin to extract specific files from some of the artifacts into some
> directories in your web application. For example the legacy avalon
> configuration files and the spring bean configuration files are
> extracted into the file system.
> 
> Before discussing a solution for this, let's have a look at what is
> currently handled by the deploy plugin (please correct me if the
> information below is wrong):
> 
> Currently the deployer plugin handles:
> a) COB-INF/** - these are all application resources of the block
>                 like the sitemap, stylesheets etc.
> 
> 
> b) META-INF/legacy/xconf/** - Block specific avalon config files
> 
> c) META-INF/legacy/sitemap-additions/** - Block specific avalon config
>                                           files for sitemap components
> 
> d) META-INF/spring/** - Block specific spring config files
> 
> e) META-INF/properties/** - Block specific properties
> 
> f) META-INF/legacy/cocoon.xconf - The main avalon config file
> 
> g) WEB-INF/classes/** - Block specific resources for the classpath
> 
> h) WEB-INF/db/** - Support for the hsqldb block
> 
> i) META-INF/xpatch/*.xweb - Patches for web.xml
> 
> I think we can simplify this a little bit:
> - No block should contain a cocoon.xconf - this file is either created
> by using an archetype or by directly writing it per hand - so we should
> drop the support for f)

+1

> - I see no use for g). We can simply put the resources "directly" into
> the jar file.

+1

> - I have no clue for h) and i) right now, but they are not very common
> use-cases.

We had a long discussion about i) at the end of August. Maybe Lezek, who 
integrated this stuff can give a summary.

> - The separation between business components and sitemap components in
>   avalon is legacy as well, so I think we can all drop them into
>   "legacy/xconf", but in different configuration files.

so you mean dropping META-INF/legacy/sitemap-additions/? No problems with it.

> - Using "legacy" in the directory structure is fine, but somehow it
>   seems wrong to me that we use "legacy" during development but not
>   in the final web application (there we just use WEB-INF/cocoon/xconf).
>   So we should imho either rename "legacy/xconf" to just "xconf" or
>   put everything in the resulting webapp under "WEB-INF/cocoon/legacy":
>   the avalon configuration files and the initial cocoon.xconf.
>   For the reminder of this mail, I'll use the first solution.
> 
> This leaves the COB-INF directory and some configuration directories in
> META-INF. I know that we discussed the directory structure many times
> but today I think we should put all configuration stuff inside one
> single directory; I would suggest to put everything in the
> META-INF/cocoon directory (apart from COB-INF):
> 
> META-INF/cocoon/xconf/**
> META-INF/cocoon/spring/**
> META-INF/cocoon/properties/**
> 
> Changing this simplifies the deployer as it just has to extract the
> META-INF/cocoon directory to WEB-INF/cocoon.

+1
(maybe somebody can write some script that moves around the directories (again) 
so that they follow this.

> So the final part is how to avoid the maven deploy plugin? We recently
> discussed a possible solution which works using some classloader
> functionality, some new protocols and so on and does not require any
> extraction of files during deployment or runtime. Cocoon would be able
> to serve everything directly from the jar files.
> While this is a very interesting solution, it has some problems: first
> and most important: we have to develop it. As we are lacking resources,
> this might take too much time until we have a final version.
> 
> So what are our alternatives? I come up with the following three, but
> perhaps there are more:
> a) We don't care and require people to use maven2 for their development
> (or if they don't want to use maven2 they have to figure out how to do it)
> b) We support other build system, for example by providing an ant task
> doing the same stuff as the maven deployer
> c) We implement a simpler solution which works for most people
> 
> a) is obviously not a good choice; 

agreed

I'm not sure about b)

doable but if we rewrite things we can go for a better solution like c)

> so I personally
> would focus on c). A solution would be to simply extract the files on
> startup of Cocoon into the web archive. We already have a place where we
> can do this (in the setting up of the properties system of Cocoon which
> is the first activity on startup) and implementing this should be fairly
> easy.
> We just have to find a smart way of not extracting everything on each
> startup - but that shouldn't be too hard.
> The only drawback I see right now is that people that want to run Cocoon
> unexpanded can't use this approach. But if someone has the opinion to
> run web apps unexpanded is the better approach, we could *for now*
> require them to use the maven plugin. We can come up with a better
> solution with upcomming versions.

do we establish any contracts? I guess the only thing is the includes in 
cocoon.xconf, right?

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

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

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