Luca Morandini wrote:
http://dictionary.reference.com/search?q=panacea ;-)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.
Nope, but SAP connectivity blocks neither, and 5 different database access methods (http://outerthought.net/gettogether/original/Tortsen-orig.pdf) also, etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be Apache projects, even better Cocoon subprojects...? Yes, of course!Or, more to the point, should a chart-producing package be inserted in the codebase ?
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.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 ).
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 andYes, 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* ;-)
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.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
