cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: problems starting 2.1.6-dev
Date Sun, 17 Oct 2004 15:53:16 GMT
Sylvain Wallez wrote:
<snip/>

> Instead of creating yet-another-small-project at cocoondev.org (like 
> my own CVSSource), what about creating a general-purpose project that 
> would host all interesting cocoon-releated things we cannot host at 
> the ASF because of license problems?
>
> Instead of having a collection of small one-man shows that sleep in 
> their corner, that may foster some collaborative work on things that 
> aren't in ASF not because of social problems, but because of legal ones.
>
> This project could also be laid out so that it's easy to slip it into 
> the main Cocoon distro (think "src/blocks/blah") and therefore allow 
> users to easily build their own bigger Cocoon.
>
> Just some thoughts.
>
> Sylvain
>
+1

I did some work on "blockifying" Fins a year ago or so. As you can see 
in the installation instructions: 
http://www.sidimar.ipzs.it/fins012/docs/install.html. There are quite a 
few steps you need to perform to install a external block into Cocoon.

The main problems is that you need to copy your block to the blocks 
directory and patching jars.xml and gump.xml. I think it would be good 
if one could (at least) optionally place the jar.xml and gump.xml 
snippet within the block. And also to have a configuration file in the 
Cocoon main directory with the positions and names of all external 
blocks, much like the mount-table.xml.

I don't know much about the build system in Cocoon, would something like 
what I described above be easy to add? Any ideas about how to handle 
external compile time blocks, so that it becomes a step in the path 
towards real blocks?

/Daniel



Mime
View raw message