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)
- 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.
- 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/**
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.
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.
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?
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
