cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: app skeleton based on YourCocoonBasedProjectAnt16?
Date Mon, 20 Dec 2004 13:39:15 GMT
Bertrand Delacretaz wrote:

> Le 20 déc. 04, à 12:23, Sylvain Wallez a écrit :
>
>> ...The problem is that you have to know beforehand what blocks we 
>> want to use, compile them and -- here comes the real problem -- 
>> generate a cocoon.xconf. If you ever want to add or remove a block 
>> later on, you have to strip down the project's cocoon.xconf or merge 
>> it with the one that resulted from a new build with more blocks...
>
>
> Taking a slightly different perspective here, I think both things can 
> be parallel: for several (rather small) recent projects I've been 
> using an application skeleton based on
> http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16, and I've 
> found it relatively easy to add and remove blocks as needed, by 
> editing one file, and also easy to add my own components by putting 
> xconf files in the appropriate directory (I've also started to use 
> hivemind as the application component manager to be decoupled from the 
> Cocoon internals at the app level but that's another story).
>
> I was thinking that we could add an "application seed" to SVN (in a 
> new "contrib" directory maybe), a skeleton that allows people to build 
> their own apps based on Cocoon, with minimal interference with 
> Cocoon's build and blocks system. In this structure, the relevant 
> parts of Cocoon are "pulled into" the application as needed, based on 
> a simple configuration file which is itself built from Cocoon's configs.
>
> IMHO this is very good for small to medium projects, and it requires 
> little knowledge about Cocoon internals to be productive.


Sorry, but I still find this too much complicated. 12 steps, involving 
ant, command-line, xpatch are way too much complex compared to my 
proposal which simply consists in moving files around and modifying 
<import> elements in a centralized file.

During trainings, many people are trying to start Cocoon by 
double-clicking on cocoon.bat and tell me "it fails to start" simply 
because this file expects an argument. Windows users are really not used 
to using the commandline.

We must come back to a binary distro which can be stripped down easily 
and started without having to open a console window. That will make 
Cocoon less scary.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message