[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Test Errors on Head Revision

Hank Grabowski <hank@applieddefense.com> a écrit :


...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.
Good catch! As most other core Orekit developers do use Linux too, we did not encounter this.
The general rule in .gitattributes for the .dat files was expected to hold for the gravity field and tides files. So the change should be to replace the two lines: 

  src/*/resources/*/*.dat             text
  src/*/resources/*/*/*.dat           text

with

  src/*/resources/tides/*.dat         text
  src/*/resources/potential/*/*.dat   text

and to add in the next section

   src/*/resources/inpop/*.dat       -text


As you have found the culprit, I let you do the change yourself.




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










----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.