cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: ChartTransformer 0.0.4 urge a commiter!
Date Sat, 25 Jan 2003 17:49:24 GMT


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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message