cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject RE: ChartTransformer 0.0.4 urge a commiter!
Date Sat, 25 Jan 2003 19:57:58 GMT

On Sat, 25 Jan 2003, Luca Morandini wrote:

> > -----Original Message-----
> > From: Nicola Ken Barozzi []
> > Sent: Saturday, January 25, 2003 8:06 PM
> > To:
> > Subject: Re: ChartTransformer 0.0.4 urge a commiter!
> >
> > I've looked at the source code, and it's one class, and it's heavily
> > tied to JFreeChart. Wings is much more abstract in this regard. I don't
> > think that it will be easy to make it renderer-agnostic.
> >
> Yep. We tried to make it as simple as possible, which has meant binding it to JFreeChart.
> > Also, the fact that it's tied to a LGPL package is something I don't like.
> Yes, this opinion of yours is very clear.
> > The fact that you want to continue with adding many features to it makes
> > me think that you will need quite a lot of freedom too.
> No. It is just that we don't want to lose our momentum. Moreover, we'd like to add XY
graphs to make it truly a charting solution.
> > I think you should set it up on cocoondev and chenge the license to APL
> > compatible, for all the reasons I said in my email
> ChartTransformer is already APL, only JFreeChart is not. Moreover, as Steven suggested,
the codebase my be offically donated to
> Apache.
> > Fnally, if there is going to be *a* charting package, it should be
> > renderer agnostic. If not, they should have their own names (as FOP is
> > not FO, itext is not called PDF).
> I don't agree that it should neessarly be render-agnostic, since there is NO open-standard
for charting.
> Conversely I agree on changing its name: JFreeChartTransformer would give the people
developing JFreeChart their due :)

That reminds me with my discussion with Stefano etc. for year ago.

Luca, your ChartTransformer very intersting, and it will not be more
interesting, if it's part of the cocoon codebase.

I have also written a DiagramSerializer(yes ;-) I'm not joking).
In the past I adding the Slide support and the chaperon parser components
to the Cocoon codebase. But time went by, and I think more and more
that blowing up the codebase wasn't a good way :-/
If I set up a new webapp, I must always remove parts, which I don't

We respect your good will! Try first cocoondev or sourceforge, believe me.

Stephan Michels.

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

View raw message