cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: ChartTransformer 0.0.4 urge a commiter!
Date Sat, 25 Jan 2003 14:31:21 GMT
Luca Morandini wrote:

> Steven, this begs another question: what's should be inside Cocoon ? ;-)

I promised to start a Wiki page about that, but haven't come across some 
copious free time yet. _My_ main problem in researching this is the 
disjunction between package hierarchy and organizational decomposition. 
I see many blocks right now, but no neat organizational decomposition.

To me, a component/block has not only a 'separateable' implementation, 
which shows in the package naming and the fact it being a block, but 
also some 'principal caretaker', if I may say so in an open source 
project where all code belongs to the community. A component should also 
have a separate release schedule/lifecycle (not in the Avalon sense), 
and would require a well-defined _release_ version of Cocoon. Take 
XMLForm as an example: it will only be 'released' when 2.1 is out. And 
new releases of it thereafter will remain dependent on the release cycle 
of Cocoon.

OK, I'm not the coding wizard, but this is basically the _functional_ 
reason of the existence of blocks in my perspective. But I fear that 
this vision behind blocks will never come true if we don't separate 
blocks physically from the Cocoon core. Blocks-people, correct me when 
my assumption is wrong.

> Or, more to the point, should a chart-producing package be inserted
> in the codebase ?

Nope, but SAP connectivity blocks neither, and 5 different database 
access methods 
( also, 
etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be 
Apache projects, even better Cocoon subprojects...? Yes, of course!

> A) If the answer is yes (as it is now), sooner or later a decision
> should be made between Wings and ChartTransformer (supporting both
> doesn't seem sensible to me ).

See above, there might be room for n implementations, and the nature of 
open source is that the 'best' will survive. I advocate some garbage 
collection if some component becomes MIA.

So I don't see why two implementations of the same problem can't coexist 
in one repository, but I don't believed in 'forced' integration or 
merging, as a requirement before one of them being added. Not anymore: 
this community alchemy has been tried and tested before, and I don't 
think it works. If Wings & ChartTransformer have a reason to integrate, 
that will eventually happen, but not because someone made it a 
requirement. It might happen only because of the intrinsic need to 
integrate (for technical or human reasons) both implementations. As it 
is now, these reasons apparently don't exist, and I have no problems 
with that. I have a problem (and you will see me bringing this up on 
each opcoming addition) with the fact new stuff gets added to the core 
if it can be done equally well outside it, especially since we now have 
the possibility to address these things structurally, by establishing 
Cocoon subprojects and whatelse.

> B) If the answer is no, then delete Wings from the codebase and
> insert in the doc that users can create charts with Cocoon by 
> downloading Wings and/or ChartTransformer from Krysalis and/or
> CocoonDev.
> Well, in all fairness, I'd like "my" package to enter into the
> standard Cocoon distro... partly because I need to feed my ego (the 
> Nirvana is still ahead of me ;) ), partly because I think that it
> could be a good selling point for Cocoon.

Yes, it is. And don't worry about that Nirvana thing: if 
ChartTransformer gets added to _a_ Apache Cocoon CVS repository, your 
help will be needed and the appropriate privs will be granted. And if 
your ego needs care: *big sloppy kiss* ;-)

Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  
stevenn at                stevenn at

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

View raw message