Nicola Ken Barozzi wrote:
In Cocoon we already have a chart transformer, based on Krysalis Wings. It has evolved, and now we use JCharts, that is APL compatible.Evolved? It requires some serious work, you mean. You are overselling Wings, Nicola. Wings has a committers base which is rather inactive, and the Cocoon stuff is quite poor feature-wise when compared to ChartTransformer.
(don't start defending Wings or its committers base, I know Tom very well and I know he can cope with such a message - especially since we (xreporter) are one of the few who actually tried to put it to use)
Wings has the possibility of using different charting packages as back-ends, and JFreechart too, but it ships with jCharts as default.It has been suggested before that ChartTransformer and Wings could cooperate, but due to time-to-market and technical issues, each group went its own way. So be it. Software Darwinism.
I'd personally prefer that we use a completely APL-compatible system for charting. Overmore Wings has been developed with separation of content and syle in mind...
Anyway, I really don't want to stop this, but I'd like that we decide what we want to do.
The fact is that putting something in Cocoon CVS makes it somewhat "standard". If this solution had been there for some time, it would be a sure bet, and can be inserted by name.
From a Cocoon perspective, this is the nth example of my recurrent theme/worry that we are adding too much stuff to the core CVS. Or we should make more active use of the cocoon-apps module, or stuff should be moved to cocoondev.org. Either way I'm happy. Blocks ain't good enough, if the xml-cocoon2 repository keeps on growing in terms of size.
I loath to see people creating stuff outside this community, but with the intent to have it moved into Cocoon afterwards. Sorry to say so, and please don't take this as a criticism. I think, given our new independence and responsability that comes with being being a toplevel project, we should worry about long-term oversight of Cocoon code (and don't be mad, Luca, it's with the best intentions). AAMOF, I proposed to Luca to move to cocoondev.org minutes after seeing his mail, so that we get a publicly accessible CVS repository.
In this case we have two different charting transformers, which to insert?Sure. If more people, and hopefully Tom and other Wings folks, become stewards of 'the' Cocoon charting codebase, we can commit either solution, or both, or one solution as we see fit. But as I said in the SAP R/3 case, this won't solve the problem of the corpulent codebase, and the issues with oversight that comes with its weight. Your efforts in blockifying stuff have already unearthed several issues, and I think we should actively try to keep the core codebase clean & healthy.
IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that this transformer be hosted on cocoondev so that it can grow.
And I'd like that we get to combine efforts, so that we can commit a unified version to the Cocoon CVS.
</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]
