How to build JFreeChart from SVN

[matinh]

Hi!

I checked out JFreeChart from Sourceforge.net using SVN. Now I'm trying to run the unit tests but they do not compile due to an (IMHO) invalid classpath in the ant build file. In ant/build.xml the classpath for compiling the tests is defined as follows:

Code: Select all

<classpath>
  <path refid="build.classpath"/>
  <pathelement location="${junit.jar}"/>
  <pathelement location="${basedir}/${jfreechart.name}-${jfreechart.version}.jar"/>
  <pathelement location="${basedir}/${jfreechart.name}-${jfreechart.version}-experimental.jar"/>
  <pathelement location="${basedir}/build-tests"/>
</classpath>

But the JARs that are created earlier during the build are located at ${basedir}/lib/. Is the classpath incorrect or am I supposed to do some copying before running the tests?

Further on, when I correct the classpath problems and run the tests with Java 6, some of them do not pass. The compiler says

Code: Select all

The method assertEquals(Object, Object) in the type Assert is not applicable for the arguments (double, double)

According to Eclipse there is no Method assertEquals(double, double). There are, however, assertEquals(Object, Object) or assertEquals(double, double, double). Are the tests incorrect or do have to use a specific Java version which autoboxes the doubles?

Any ideas?

- martin

[mkrauskopf]

Are the tests incorrect or do have to use a specific Java version which autoboxes the doubles?

I believe so. One thing is that JFreeChart is supposed to be used with JDK 1.4 and higher so autoboxing cannot be used (at least for version 1.0.x as far as I understand it). Other is that jfreechart-1.0.x-branch uses JUnit 3.8.1 which does not have method assertEquals(double, double). Seemingly such method was reintroduced in JUnit 4.4 (http://junit.sourceforge.net/doc/ReleaseNotes4.4.html). So author(s) of the tests likely used different version of JUnit during development then the one bundled within JFreeChart repository? Anyway such method should not be used (and is deprecated) due to problems wrt. floating point arithmetic (see e.g. http://stackoverflow.com/questions/5686 ... ble-values)

I've fixed the 'test' target (in the way you suggested) and test classes in my patching-fork at https://github.com/mkrauskopf/jfreechart-patches.

But for the case when you want to just compile the library itself (without running tests), I'm using ant -f ant/build.xml compile-experimental compile.

Cheers,
m.

[matinh]

Hi!

The problem with doubles not only exists in the tests but also in the classes XYAreaRenderer and XYAreaRenderer2. Therein the moveTo(float, float) or lineTo(float,float) methods of the GeneralPath class are used with double arguments, which also leads to compile errors in my environment. So I guess David used a different development environment.

Your fix in github seems correct, but requires a recent JUnit version, which eventually is not compatible with and old Java version. I didn't check, so I might be wrong here.

What I actually would really like to know is, what is the exact environment under which JFreeChart should be compiled, tested and released. Hopefully David will respond, so we can fix the problems also in the SVN repository.

- martin

[mkrauskopf]

The problem with doubles not only exists in the tests but also in the classes XYAreaRenderer and XYAreaRenderer2
--%<--

Yup, I've fixed those some time ago: https://github.com/mkrauskopf/jfreechar ... d9e197f52f

Your fix in github seems correct, but requires a recent JUnit version, which eventually is not compatible with and old Java version. I didn't check, so I might be wrong here.

I think you are wrong. JUnit 3.8.1 contain version with delta: http://www.junit.org/junit/javadoc/3.8. ... ssert.html . I can run ant -f ant/build.xml test with JDK 1.4 successfully (i.e. it compiles and run, one tests fails which is another issue).

What I actually would really like to know is, what is the exact environment under which JFreeChart should be compiled, tested and released. Hopefully David will respond, so we can fix the problems also in the SVN repository.

As I said it should be 1.4 for JFreeCharts 1.0.x. I've tried to provide patches in the "beginning" via tracker but there were no response. That was the reason why I'm tracking them in other public repository. I would prefer to not having to set up new repo, but it's easiest way for me now.

[matinh]

Yup, I've fixed those some time ago: https://github.com/mkrauskopf/jfreechar ... d9e197f52f

Ah, I see.

As I said it should be 1.4 for JFreeCharts 1.0.x. I've tried to provide patches in the "beginning" via tracker but there were no response. That was the reason why I'm tracking them in other public repository. I would prefer to not having to set up new repo, but it's easiest way for me now.

So you are probably happy to hear, that David is already preparing to reactivate JFreeChart again

Thanks for your help,
- martin

[mkrauskopf]

So you are probably happy to hear, that David is already preparing to reactivate JFreeChart again

That would be nice. I see now David's post in other thread (I did not check forum for longer time due to spam affair).

I'll then try to polish all my patches and contribute them to the SVN.

Cheers,
m.

[david.gilbert]

I checked out JFreeChart from Sourceforge.net using SVN. Now I'm trying to run the unit tests but they do not compile due to an (IMHO) invalid classpath in the ant build file.

Are you checking out trunk or the jfreechart-1.0.x-svn branch. Well, in any case I am checking out the branch right now so I should find out soon.

[david.gilbert]

On a clean checkout of the branch, 'ant -f ant\build.xml' compiles everything successfully (jdk1.7.0, Windows, Ant 1.8.2). There are a couple of Ant warnings that I will look at, and a lot of Javadoc warnings (there didn't used to be any at all, so I think that either the new javadoc in JDK1.7 is causing an issue or detecting problems that older versions did not report). In any case, I'd like the build to complete with zero warnings, so I'll look at that too.

'ant -f ant\build.xml test' (which should compile and run the tests) is failing. Let me check Martin K's patch.

[david.gilbert]

Patch is applied, so the classpath is fixed. Now there's a bunch of compilation errors for the tests. That will be my next investigation. It looks to be related to auto-boxing / unboxing as Martin mentioned already. It wouldn't be a problem on old JDKs, but this needs to work out-of-the-box on JDK 6 and 7.

[mkrauskopf]

...Now there's a bunch of compilation errors for the tests. That will be my next investigation...

Those are fixed on my patching-fork as well. This commit: https://github.com/mkrauskopf/jfreechar ... 5d2422ccc7

It should compile and run on all JDKs since JDK 1.4 AFAIK.

Cheers,
- m.

[matinh]

Hi David!

In case you still want to know, I was using jfreechart-1.0.x-svn branch.

Building without tests now works using ant with JDK 1.5.0_18 and JDK 1.6.0_26. But I definitely got compile errors in XYAreaRenderer when compiling from within eclipse on another machine (which I don't have access to right now). mkrauskopf got the same errors, so it seems there are some problems. (They have been introduced by this change). His fix mentioned above worked for me and seems reasonable.

In mkrauskopf's git repo the test-compile errors are already fixed. Maybe you should just use this patch.

- martin

[matinh]

Hi again!

(David, I sent you already an email about this but it would probably better be discussed on the forum.)

There is one more problem with the tests, which is actually a bug in DefaultPolarItemRenderer introduced by me 2 years ago
The reason is, that the renderer must be serializable and has an (Alpha)Composite field which is not serializable. See also
http://bugs.sun.com/bugdatabase/view_bu ... id=6821194

IMHO the best way to fix it would be to introduce read/writeObject() methods and do a manual serialization. There is already SerialUtilities.read/writeShape() from JCommon. Another method read/writeComposite() would be needed. Should I provide a patch for this?

Another possibility would be to remove the Composite from the renderer and ony have the alpha-value stored for the AlphaComposite. The construction of an AlphaComposite would then be hardcoded and we would loose some flexibility.

What do you think?

- martin

[david.gilbert]

IMHO the best way to fix it would be to introduce read/writeObject() methods and do a manual serialization. There is already SerialUtilities.read/writeShape() from JCommon. Another method read/writeComposite() would be needed. Should I provide a patch for this?

Yes, that would be great!

[david.gilbert]

In mkrauskopf's git repo the test-compile errors are already fixed. Maybe you should just use this patch.

Yes, I'm looking at his changes and they look good. Also I've not used Git before - it looks interesting.

[matinh]

IMHO the best way to fix it would be to introduce read/writeObject() methods and do a manual serialization. There is already SerialUtilities.read/writeShape() from JCommon. Another method read/writeComposite() would be needed. Should I provide a patch for this?

Yes, that would be great!

For the patch, JFreeChart as well as JCommon would need to be patched. Where can I find the actual source of JCommon?

On Sourceforge, there are a few locations:
http://jfreechart.cvs.sourceforge.net/v ... t/jcommon/ which looks outdated.
http://jfreechart.svn.sourceforge.net/v ... mon/trunk/ which looks newer but has net.sf.jcommon package names.

Any hints?

- martin