Re: [Orekit Developers] Test Errors on Head Revision

...and the mystery has been solved! I'm surprised this hasn't come up yet, since the culprit hasn't changed since 2012. It just occurred to me that I've done all my development up to date on Linux, not Windows, which is why I never saw it before.

The problem is happening because git is setup to handle CR-LF differences across systems. The *.dat files in src\test\resources\inpop are being specifically highlighted in the .gitattributes file as being text files and therefore needing to have their end of line characters searched for and managed. It became clear that was what was going on when the size of the files was off. For example the version of inpop10b_TDB_summer_1969_bigendian.dat in the zip file is 37,520 bytes. The version that is pulled down from the repository at the 6.1 tag is 37,598 bytes. If I copy the version from the zip files over top of my repository then do a "mvn clean" followed by an "mvn test" everything runs great. As soon as I revert the repository back to the version that was pulled down the error happens again.

These are binary files and should be handled as such. I think if the change is made to the .gitattributes file Linux side and then pushed up then this will fix the problem.

On Tue, Sep 23, 2014 at 3:11 PM, Hank Grabowski <hank@applieddefense.com> wrote:

I finally successfully got these creating new Eclipse workspaces, whew! Unfortunately the tests fail in the exact same manner both inside Eclipse and when run directly via Maven. I'm really at a loss for what is different between the two runs. The source data file inpop10b_TCB_summer_1969_bigendian.dat shows up identical in both my orekit-6.1 folder (which I got from a zip download and in the directory that was pulled directly from the repository. The function that reads it, JPLEphemeridesLoader.readInRecord are identical between the two versions. That should mean that the byte array it loads should be identical. However for some reason somewhere after byte 2600 they start diverging. That is the ultimate source of the error. How it is happening, I have no idea.

I'm still using JDK 7. At this point I'm also fighting Eclipse, both on Linux and Windows. If I try to build multiple workspaces pointed to different source directories using the "Existing Maven Projects" import method it fails with some bizarre errors. I have to end up blowing away my entire .eclipse and .m2 folder to have a prayer of it sucessfully building the new workspace. So I'm wrestling multiple things at the same time, unfortunately. Once things settle down I'll start debugging this again, assuming it doesn't fix itself.

On Tue, Sep 23, 2014 at 1:44 PM, Hank Grabowski <hank@applieddefense.com> wrote:
All,

I was trying to create some new development VMs and have noticed that I'm getting test errors with the head revision. I have the Maven 3.1.1 installed on both OSs. I do a clean checkout of orekit-main from the https://www.orekit.org/git/orekit-main.git link. I then run "mvn package" on the clean folder. Under Windows 7 I'm getting these test failures:

JPLEphemeridesLoaderTest.testGMInpop:111 ╗ Orekit file c:\git\orekit_ro\orekit...
JPLEphemeridesLoaderTest.testEndianness:190 ╗ Orekit file c:\git\orekit_ro\ore...
JPLEphemeridesLoaderTest.testInpopvsJPL:218 ╗ Orekit file c:\git\orekit_ro\ore...
JPLEphemeridesLoaderTest.testConstantsInpop:57 ╗ Orekit file c:\git\orekit_ro\...

Which map to the following errors in the surefire reports:

org.orekit.errors.OrekitException: file c:\git\orekit_ro\orekit-main\target\test-classes\inpop\inpop10b_TDB_summer_1969_bigendian.dat is not a JPL ephemerides binary file

org.orekit.errors.OrekitException: file c:\git\orekit_ro\orekit-main\target\test-classes\inpop\inpop10b_TCB_summer_1969_bigendian.dat is not a JPL ephemerides binary file

org.orekit.errors.OrekitException: file c:\git\orekit_ro\orekit-main\target\test-classes\inpop\inpop10b_TDB_summer_1969_bigendian.dat is not a JPL ephemerides binary file

org.orekit.errors.OrekitException: file c:\git\orekit_ro\orekit-main\target\test-classes\inpop\inpop10b_TDB_summer_1969_bigendian.dat is not a JPL ephemerides binary file

Under Linux I get a test error in the same library but it's different:

JPLEphemeridesLoaderTest.testGMInpop:114 expected:<3.24858597E14> but was:<3.24858591760573E14>

I'm surprised that the errors were different across the two OSs. I tried loading the Windows project into a fresh workspace and Eclipse and am having import problems so I can't see if it runs differently under Eclipse maven or not (but I'm investigating that on my own).

Have you guys seen this before?

Hank