cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: ChartTransformer 0.0.4 urge a commiter!
Date Sat, 25 Jan 2003 18:09:33 GMT
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

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
>> ( 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 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         
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> --------------------------------------------------------------------- To
> unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message