cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: ChartTransformer 0.0.4 urge a commiter!
Date Sat, 25 Jan 2003 18:32:29 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message