Nicola Ken Barozzi wrote:
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 >:->
Uhm. Dunnow whether you are being sarcastic or not, but yes, I think
Cocoon is going through a transition period ATM.
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.
Perfectly aware of that (I know more about blocks & hacks than you
think, Nicola ;-)
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.
Even if we complete blocks, and all the nasty sitemap grammar and
dynamic class(re)loading issues that will bring, I don't think the
matter will be over, if we don't organize the project differently. I
think what you are doing w.r.t. to blocks is a great start, BTW.
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
Yep, exactly, but I think blocks should reside outside the 'kernel' CVS.
_We_ don't stores the sources for Excalibur inside Cocoon CVS, neither.
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.
Ah. So the issue can't be discussed? :-)
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.
Yes, but I found you stating collaboration as a requirement for donation
quite 'strong'. Things don't work like that over here.
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.
I've been a happy lurker on Avalon for quite some time. This community
is quite different, as we all know.
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.
Sure. That can become the case if they are living inside the same community.
</>
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.
Uh??
</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]
