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.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.
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.
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.
Kernel?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 ?
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.
Be careful here. I've seen a community shattered to pieces because they used software darwinism as the only way of moving forward.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.
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? >;->
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.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 itYes, 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* ;-)
could be a good selling point for Cocoon.
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]
