cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [2.2] Deployment and the maven plugin
Date Thu, 02 Nov 2006 20:53:40 GMT
Carsten Ziegeler wrote:
> 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)
> - I see no use for g). We can simply put the resources "directly" into
> the jar file.


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

+1 for h)

My intention for i) was the ability for the block to contribute to 
web.xml. You can create yourself a OpenSessionInViewBlock.jar which, 
during deployment, will automatically enable the proper filter in 
web.xml. As my web.xmls in different projects stay very alike I would 
like to extract the common definitions into a reusable artifact.

This goes to any stuff that you need to put into web xml:
- filters
- listeners
- additional servlets (AFAIR some of the users used .xpath files to 
include xindice servlets in web.xml)

My common design in: webapp depends on ui-block (contributes COB-INF) 
depends on core block (contributes model and spring services) depends on 
hibernate and opensessioninview (contributes filters to web.xml)
  > - 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.


> - 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/**

I like the idea a lot - it is way clearer now.

> Changing this simplifies the deployer as it just has to extract the
> META-INF/cocoon directory to WEB-INF/cocoon.
> 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.

First of all: why don't we simply use spring functionality for that? 
Spring has a nice resource resolution. Why don't we simply reference

classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
for properties resolution?

This way we can reference the files directly from jar file without the 
need to extract it.

Moreover this automatically resolves all current problem for block 
development. Currently if you test a development block in isolation none 
of the resources are actually deployed into a webapp. Instead everything 
is referenced from src/ directory. Everything apart 

Referencing properties with 
classpath*:/META-INF/cocoon/properties/*.properties will also pick 
property files from target/classes directory of local block. Poof - the 
problem is gone.

> 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; I'm not sure about b) 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.

I have a lot of legacy cocoon based project that I would like to port to 
2.2 and without the deployer I had to move all resources from 
src/main/resources/META-INF/spring to 
src/main/webapp/WEB-INF/cocoon/spring so they get properly detected at 
runtime. It would simplify a lot of things for me if we referenced 
spring context anywhere on the classpath (in a proper dir of course).

> 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.
> So, wdyt?

Could the archetype stop putting cocoon.xconf into generated webapp? I 
have at last 10 projects running 2.2 and never touched this file in any 
project. It only gives me headaches when cocoon-core changes and I have 
to update it manually from cocoon sources (Last time all my projects 
broke after the namespaces have been renamed). That is why I think we 
should move the configuration stuff (log4j configuration file location - 
why isn't this controlled by properties after all?) out of the file and 
either reference it directly from cocoon-core.jar or remove it 
completely (create proper beans programatically at runtime).

Currently cocoon.xconf is only modified by cocoon deployer itself when 
it creates appropriate imports to load development block resources 
directly from source. As I proposed another way of handling it I think 
we can drop this feature also.

Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message