cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 16:30:10 GMT
>> Also, can you comment on Andrew's suggestion:
> I'm doing it since months now, it's called Centipede.
> We are moving right now with the help of Ant-dev to a new level with 
> build imports, and it will be proposed to Cocoon ASAP.

No...this is no really an even match with centipede.  I mean a nice big 
fat menu that it would be nice to be able to run in text  mode as well 
that reads in a property file with
lines like

./ textconfig would say

"Include Batik [Y/N/H]"?
"Include POI   [Y/N/H]"?

Hitting H would get a description such as....

"POI and the associated serialization support classes provide XML 
serialization to legacy formats such as Microsoft Excel 97 and Word.  In 
short if you need to generate XLS spreadsheets from XML documents, say 
yes here, otherwise its safe to say N"

"Batik and its associated serialization support classes provide support 
for generating Scalable Vector Graphics and converting them to other 
formats.  If you wish to, for instance, generate JPGs on the fly from 
text strings, or bla bla then say yes here, otherwise
its safe to say no"

Following this you could do:

./ configuredwar

and out would come your cocoon with only what you wanted!

We don't necessarily need centipede for this, nor is this necessarily 
provided by centipede, though cents supporting this might make it 

>> And Konstantin's:
> We don't really need different editions, Cocoon core is not that big.
> What we need is instead the possibility of using Cocoon in different 
> environments, hence the Bean (embedded), CLI (standard) and 
> servlet/Phoenix (enterprise.)


>> And Berin's:
> We need to sepate implementations where needed and group them when 
> not, a simple rule of -all separate- or -using same libs- is not 
> enough, since there will always be many shared dependencies.
> We need a list of the impls and the proposed "components".
>> My other reason is: the more (playground) directories we create, the
>> more messy MAIN becomes. And, one cannot work with HEAD, because you
>> cannot commit to HEAD.
> I said BRANCH, not subdirs.
He means when you create subdirs in the branch.  


To unsubscribe, e-mail:
For additional commands, email:

View raw message