Eastwood rewriting

A discussion forum for the Eastwood Chart Servlet.
solid
Posts: 1
Joined: Mon Aug 11, 2008 7:19 pm

I need maven version

Post by solid » Mon Aug 11, 2008 7:27 pm

I saw this thread and I was hoping to get some clarification. I would like to use Eastwood charts in an app I am developing for a bank but I have some questions.

1) Under the lgpl terms, is it acceptable to bundle eastwood with a commercial closed source app, provided I do not alter the code?
2) where is the maven version hosted? I really need a drop in dependency entry for my pom as I have a bunch of junior developers working this project that are only marginally familiar with maven. I would prefer to not have to set up external repositories etc.
3) (True or false) Eastwood does *NOT* rely on any external resource at runtime to generate the charts?
4) Are there any plans to make this project officially mavenized?

david.gilbert
JFreeChart Project Leader
Posts: 11734
Joined: Fri Mar 14, 2003 10:29 am
antibot: No, of course not.
Contact:

Re: I need maven version

Post by david.gilbert » Tue Aug 12, 2008 11:13 am

solid wrote:1) Under the lgpl terms, is it acceptable to bundle eastwood with a commercial closed source app, provided I do not alter the code?
Yes. You have to make the Eastwood source code available to your customers, but the code for your app can remain proprietary.
solid wrote:2) where is the maven version hosted? I really need a drop in dependency entry for my pom as I have a bunch of junior developers working this project that are only marginally familiar with maven. I would prefer to not have to set up external repositories etc.
I'm totally ignorant about Maven. Another developer contributed a POM file, which I committed to Subversion but, alas, didn't update the Ant script to include it in the distribution:

http://eastwood.svn.sourceforge.net/vie ... iew=markup

I'm relying on others to make this usable.
solid wrote:3) (True or false) Eastwood does *NOT* rely on any external resource at runtime to generate the charts?
True. Eastwood generates the charts locally (i.e. on your server) using JFreeChart (which in turn uses Java2D).
solid wrote:4) Are there any plans to make this project officially mavenized?
I don't know what "officially mavenized" means, so I guess the answer is no.
David Gilbert
JFreeChart Project Leader

:idea: Read my blog
:idea: Support JFree via the Github sponsorship program

david.gilbert
JFreeChart Project Leader
Posts: 11734
Joined: Fri Mar 14, 2003 10:29 am
antibot: No, of course not.
Contact:

Post by david.gilbert » Tue Aug 12, 2008 11:51 am

Sorry it has taken me so long to reply...
cblin wrote:Firstly, I did not find the pom.xml in the 1.1.0 zip release so I can not comment on it...
I forgot to update the Ant build.xml file to copy the pom.xml into the distribution. That is fixed in Subversion now for the next release.
cblin wrote: * dataType = 0, 1, 2; => private static final int CONSTANT could be used to improve the code clarity, moreover there are 3 and 4 used in the file and they are undocumented...
Yes, that stuff is a bit cryptic. I'll fix it.
cblin wrote: * removing the warnings concerning the serialVersionUid is quite simple and should be done to improve error localization
Agreed. On the to-do list.
cblin wrote: * a subpackage to identify what is jfreechart related could be done too (even if it is not named org.jfree.chart but org.jfree.eastwood.chart for example). ATM, it is quite hard for a beginner in jfreechart like me to locate where I could help and where I can not and also which class inherits from what.
Yes, that does make sense. I'll move those classes (all the ones with names starting with 'G' - which I used to denote that they are extensions to JFreeChart classes specifically to emulate features in the "Google" chart API).
cblin wrote: * there should be 1 method by step : when you know that something has gone wrong in the axis, you could watch in the processAxis method (and there should be a method with only calls to submethods for beginners that are willing to understand the chart generation process). This is easy to do with IDE refactoring functionnalities...
Here you mean splitting up the ChartEngine.buildChart() method, right? Into separate methods for each step in the process, correct? That makes sense.
cblin wrote:Also, junit.jar is not available in the lib directory so that it is unclear which version should be used to run the tests (3.8.1 seems ok).
The tests of the ChartEngine are very lite though...
I'll put a JUnit file in there. I forget which version I was using, but I'll check (most likely the same one as for JFreeChart). More tests are required, I just figured adding some was better than none at all.
cblin wrote:concerning the image map, I do not get your point.
Installing an URL generator is what I did with the entity.setURLText, isn't it ?
Somewhere deep in JFreeChart the setURLText() method gets called to set the text that has been obtained from the URLGenerator. I think you are then overwriting it with your own URL. It's no big deal, but if you can get your URLs into a URLGenerator and let JFreeChart populate the ChartEntities, then you will have a "cleaner" solution (having said that, you'll need more knowledge of the JFreeChart internals to make that work).
cblin wrote:Finally, I need feedback on the image map parameter : is the format "id_map|TITLE|LEGEND1|LEGEND2|...|SECTION1|SECTION2|...|drill_url" ok ?
I think this is OK, except that maybe you are assuming that the ChartEntities returned by JFreeChart are in a fixed order, which might be a little fragile. I wonder if it would be more robust to specify the data item URLs separately from the title and legend URLs, and make the link between the data item and the URL by actually checking the ChartEntity subclass and info.
David Gilbert
JFreeChart Project Leader

:idea: Read my blog
:idea: Support JFree via the Github sponsorship program

cblin
Posts: 12
Joined: Sun Jun 08, 2008 6:35 pm

Post by cblin » Tue Aug 12, 2008 12:25 pm

david.gilbert wrote:Sorry it has taken me so long to reply...
No big deal because we have finally delayed our development based on eastwood to september.

I'm glad you include my points on the TODO list.

I'll probably submit patches during september :
* image map
* minor code improvements listed in the above post

For the unit test cases, you said that the generated images were different on each platform. That is understood.
Then, I wonder if this is the same for the image maps ?
If no (i.e the image map is the same whatever the platform), then the unit test cases can be done on the image map result.
And then we ca assume that if the image map is correct then the image is correct too (and so, refactoring and new functionnalities will be easier to test).
What do you think ?

Locked