Oops. I wrote the initial mail of the thread in the good sense. I think that Cocoon need a chart transformer as it use a PDF serializer, MP3 directory generator and so on. By the way into Cocoon we see 2 PDF serializer:
itext and FOP. I never thinked it will trig a hot discusion. Sorry for that. Antonio Gallardo. Nicola Ken Barozzi dijo: > > > Steven Noels wrote: >> Luca Morandini wrote: >> >>> Steven, this begs another question: what's should be inside Cocoon ? > > [...] >> 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. > > So should Bugzilla, so should the site, so should the build... right? > More organization, this is too chaotic >:-> > >> 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. > > Steven, probably you're dreaming. We don't have blocks (yet). We have > just separated code from the core and are trying to hack a block > implementation. > > The day they will *effectively* be able to be compiled and added to > Cocoon in a complete separate fashion, I will want to see it too. > Probably you don't know how it works that much now. > >>> 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 >> (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! > > Kernel? > > src/java/** == kernel > src/blocks/** != kernel > > Do I see a time when cocoon.apache.org has a section where the blocks > have their own lifecycle, are detatched from core and the development > bubbles of activity? > > Yes. > > Is it possible *now*? > > Nope. > >>> 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. > > Be careful here. I've seen a community shattered to pieces because they > used software darwinism as the only way of moving forward. > > It breaks communities, makes egos grow, and doesn't make it possible for > the project to go forward. > > One thing is having competing codebases based on technical differences, > one is competing people. Do you really think a charting block has such > different architectural needs that competition is needed? Come 'on... > > Competition is a poor substitute of collaboration. > >> 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. > > Tried and tested? Where? > The opposite was tries and tested. It's called Avalon (Excalibur(ECM, > Merlin, Fortress,...), Cornerstone, Phoenix, ...), and it was a > community failure. > >> 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 never said it has to be a requirement. If Cocoon is to have *a* > charting package, I'd like to see them integrated, and not see > JFreeChart used as a default implementation. > > In the other case, the two can coexist, but it seems stupid to me. If we > cannot cooperate in a charting package... heck, it's ridiculous! > >> 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. > > It's *not* the core. We *will* move blocks outside. Moving code away > without a community around == killing it. > > So now it's impossible. Anyone wants to make blocks a reality *finally*? > Steven? >;-> > >>> 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... > > Once it's in the Cocoon distro it's not going to be *your* package > anymore. I would surely add the features that I want to see that are in > Wings now, and a merge will happen anyway. Don't assumed it will > necessarily remain that way. > >>>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* ;-) > > Nice joke Steven, nice joke. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
