Failed tests:
testValidateEPUBvalid20(com.adobe.epubcheck.api.Epub20CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBvalidIssue169(com.adobe.epubcheck.api.Epub20CheckTest):
[creation date] 1305812502000 not found
testValidateEPUBPvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBTestSvg(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBMp3(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBMp3WithFallback(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBFontFallbackChain(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUBvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUB30ValidExtension1(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1314890214000 not found
testValidateEPUB30CSSProfile(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1323797838000 not found
testValidateEPUB30Issue158(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1330492368000 not found
testValidateEPUB30specValid(com.adobe.epubcheck.api.Epub30CheckTest):
[creation date] 1329214800000 not found
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 39.948s
[INFO] Finished at: Thu Oct 25 15:00:17 BST 2012
[INFO] Final Memory: 18M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.10:test
(default-test) on project epubcheck: There are test failures.
[ERROR]
[ERROR] Please refer to
/Users/lotia/anobiidev/epubcheck/branches/epub3-maven/com.adobe.epubcheck/t arget/surefire-reports
for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> Hello All,
> When attempting to build a jar within the epub3-maven branch
> I do the following within the
> epubcheck/branches/epub3-maven/com.adobe.epubcheck directory which
> results in a build failure because some test fail.
> I have included the full transcript of the mvn package command below.
> Failed tests:
> testValidateEPUBvalid20(com.adobe.epubcheck.api.Epub20CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBvalidIssue169(com.adobe.epubcheck.api.Epub20CheckTest):
> [creation date] 1305812502000 not found
> testValidateEPUBPvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBTestSvg(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBMp3(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBMp3WithFallback(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBFontFallbackChain(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUBvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUB30ValidExtension1(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1314890214000 not found
> testValidateEPUB30CSSProfile(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1323797838000 not found
> testValidateEPUB30Issue158(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1330492368000 not found
> testValidateEPUB30specValid(com.adobe.epubcheck.api.Epub30CheckTest):
> [creation date] 1329214800000 not found
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 39.948s
> [INFO] Finished at: Thu Oct 25 15:00:17 BST 2012
> [INFO] Final Memory: 18M/81M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
> (default-test) on project epubcheck: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /Users/lotia/anobiidev/epubcheck/branches/epub3-maven/com.adobe.epubcheck/t arget/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> -- > You received this message because you are subscribed to the Google Groups "epubcheck" group.
> To post to this group, send email to epubcheck@googlegroups.com.
> To unsubscribe from this group, send email to epubcheck+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/epubcheck?hl=en.
On Fri, Oct 26, 2012 at 12:57 AM, Romain Deltour <rdelt...@gmail.com> wrote:
> Can you please send more details about your environment (available by running "mvn -v") ?
> I've just tested the build successfully on:
> - Mac OS X 10.8.2 / Java 1.7.0_07 / Maven 3.0.4
> - Ubuntu 12.04 / Java 1.6.0_24 / Maven 3.0.4
> Thanks,
> Romain.
> On 25 oct. 2012, at 16:05, Ali Asad Lotia <ali.asad.lo...@gmail.com> wrote:
>> Hello All,
>> When attempting to build a jar within the epub3-maven branch
>> I do the following within the
>> epubcheck/branches/epub3-maven/com.adobe.epubcheck directory which
>> results in a build failure because some test fail.
>> I have included the full transcript of the mvn package command below.
>> Failed tests:
>> testValidateEPUBvalid20(com.adobe.epubcheck.api.Epub20CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBvalidIssue169(com.adobe.epubcheck.api.Epub20CheckTest):
>> [creation date] 1305812502000 not found
>> testValidateEPUBPvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBTestSvg(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBMp3(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBMp3WithFallback(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBFontFallbackChain(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUBvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUB30ValidExtension1(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1314890214000 not found
>> testValidateEPUB30CSSProfile(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1323797838000 not found
>> testValidateEPUB30Issue158(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1330492368000 not found
>> testValidateEPUB30specValid(com.adobe.epubcheck.api.Epub30CheckTest):
>> [creation date] 1329214800000 not found
>> [INFO] ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 39.948s
>> [INFO] Finished at: Thu Oct 25 15:00:17 BST 2012
>> [INFO] Final Memory: 18M/81M
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
>> (default-test) on project epubcheck: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to
>> /Users/lotia/anobiidev/epubcheck/branches/epub3-maven/com.adobe.epubcheck/t arget/surefire-reports
>> for the individual test results.
>> [ERROR] -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>> --
>> You received this message because you are subscribed to the Google Groups "epubcheck" group.
>> To post to this group, send email to epubcheck@googlegroups.com.
I'm confused: I just ran it successfully on the following environment, which is almost the same as yours (except for the OS X version, which shouldn't impact the build or tests):
$ mvn -v
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/local/Cellar/maven/3.0.4/libexec
Java version: 1.6.0_37, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
Is your subversion working copy up-to-date and with no local modifications ?
If yes, can you maybe try to (temporarily) rename your ~/.m2 Maven local repository to start from a clean Maven environment ?
Romain.
On 27 oct. 2012, at 14:39, Ali Asad Lotia <ali.asad.lo...@gmail.com> wrote:
> On Fri, Oct 26, 2012 at 12:57 AM, Romain Deltour <rdelt...@gmail.com> wrote:
>> Can you please send more details about your environment (available by running "mvn -v") ?
>> I've just tested the build successfully on:
>> - Mac OS X 10.8.2 / Java 1.7.0_07 / Maven 3.0.4
>> - Ubuntu 12.04 / Java 1.6.0_24 / Maven 3.0.4
>> Thanks,
>> Romain.
>> On 25 oct. 2012, at 16:05, Ali Asad Lotia <ali.asad.lo...@gmail.com> wrote:
>>> Hello All,
>>> When attempting to build a jar within the epub3-maven branch
>>> I do the following within the
>>> epubcheck/branches/epub3-maven/com.adobe.epubcheck directory which
>>> results in a build failure because some test fail.
>>> I have included the full transcript of the mvn package command below.
>>> Failed tests:
>>> testValidateEPUBvalid20(com.adobe.epubcheck.api.Epub20CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBvalidIssue169(com.adobe.epubcheck.api.Epub20CheckTest):
>>> [creation date] 1305812502000 not found
>>> testValidateEPUBPvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBTestSvg(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBMp3(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBMp3WithFallback(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBFontFallbackChain(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUBvalid30(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUB30ValidExtension1(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1314890214000 not found
>>> testValidateEPUB30CSSProfile(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1323797838000 not found
>>> testValidateEPUB30Issue158(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1330492368000 not found
>>> testValidateEPUB30specValid(com.adobe.epubcheck.api.Epub30CheckTest):
>>> [creation date] 1329214800000 not found
Hi Romain,
I have now tried it on a CentOS 6.3 machine on which I have installed
maven 3.0.4 and I get the same output. It is downloading all the
required dependencies since it is creating a fresh local maven repo. I
have also tested with renaming my existing maven repo on my MacOS
10.6.8 machine and it fails the same 10 unit tests as are failed
below.
--
Ali
I just commited some corrections in r370. While doing my tests, I run into the same issue than you and I appears that some file texts used during tested where encoded in UTF-8 with BOM which make the test to fail.
Could you please retry your build and let me know?
On Monday, October 29, 2012 4:54:16 PM UTC+1, lotia wrote:
> Hi Romain, > I have now tried it on a CentOS 6.3 machine on which I have installed > maven 3.0.4 and I get the same output. It is downloading all the > required dependencies since it is creating a fresh local maven repo. I > have also tested with renaming my existing maven repo on my MacOS > 10.6.8 machine and it fails the same 10 unit tests as are failed > below. > -- > Ali
I believe Ali's issue below was not an encoding issue. The problem is that the creation date field in the text file reports is time-zone sensitive. The fix would be to output a creation date relative to UTC when writing to the test reports or to simply get rid of the text file reports altogether, which do not really belong to the unit tests IMHO.
Anyway, wrt encoding issues, I did face an issue some time ago due to a text report file that was encoded in latin1 but opened as utf8, but I transcoded the file since then.
The tests run fine on revision 371 (if you're in the CET zone).
Romain.
On 2 nov. 2012, at 21:25, Thomas <tledou...@gmail.com> wrote:
> I just commited some corrections in r370.
> While doing my tests, I run into the same issue than you and I appears that some file texts used during tested where encoded in UTF-8 with BOM which make the test to fail.
> Could you please retry your build and let me know?
> Thanks in advance
> Thomas
> On Monday, October 29, 2012 4:54:16 PM UTC+1, lotia wrote:
> Hi Romain, > I have now tried it on a CentOS 6.3 machine on which I have installed > maven 3.0.4 and I get the same output. It is downloading all the > required dependencies since it is creating a fresh local maven repo. I > have also tested with renaming my existing maven repo on my MacOS > 10.6.8 machine and it fails the same 10 unit tests as are failed > below. > -- > Ali
this is quite peculiar. Indeed, the [creation date] comes from the
time of the container.xml file in the zip container. From
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/zip/ZipEntry.h...,
the time is supposed to be "the entry modification time in number of
milliseconds since the epoch". So for me this information should not
depend on the local timezone !!! I will look into that to understand
why this value varies.
By the way, the text files in the test environment are not test
reports; they are just reference information (some interesting part of
the report) to be matched with the actual generated reports as part of
the unit tests.
> I believe Ali's issue below was not an encoding issue. The problem is that
> the creation date field in the text file reports is time-zone sensitive. The
> fix would be to output a creation date relative to UTC when writing to the
> test reports or to simply get rid of the text file reports altogether, which
> do not really belong to the unit tests IMHO.
> Anyway, wrt encoding issues, I did face an issue some time ago due to a text
> report file that was encoded in latin1 but opened as utf8, but I transcoded
> the file since then.
> The tests run fine on revision 371 (if you're in the CET zone).
> Romain.
> On 2 nov. 2012, at 21:25, Thomas <tledou...@gmail.com> wrote:
>> Hi Ali,
>> I just commited some corrections in r370.
>> While doing my tests, I run into the same issue than you and I appears
>> that some file texts used during tested where encoded in UTF-8 with BOM
>> which make the test to fail.
>> Could you please retry your build and let me know?
> this is quite peculiar. Indeed, the [creation date] comes from the
> time of the container.xml file in the zip container. From
> http://docs.oracle.com/javase/1.4.2/docs/api/java/util/zip/ZipEntry.h...,
> the time is supposed to be "the entry modification time in number of
> milliseconds since the epoch". So for me this information should not
> depend on the local timezone !!! I will look into that to understand
> why this value varies.
Well, the ZIP contains no info on the time zone where the ZIP entry was created, so the API returns the entry modification time by assuming that the entry was created in the same time zone as the current one.
In other words, if you call ZipEntry#getTime on two different time zones, you will get two different values.
> By the way, the text files in the test environment are not test
> reports; they are just reference information (some interesting part of
> the report) to be matched with the actual generated reports as part of
> the unit tests.
I know, but I believe that it does not make a lot of sense to test that the report matches for each single test method. The "unit" tests are quite focused ; testing the entire report info makes it a tad more dependent on non-related parts of epubcheck. Additionally, it's a bit more difficult to maintain since every time we will like to update the text report format we will need to re-generate the reports for all the test samples.
>> I believe Ali's issue below was not an encoding issue. The problem is that
>> the creation date field in the text file reports is time-zone sensitive. The
>> fix would be to output a creation date relative to UTC when writing to the
>> test reports or to simply get rid of the text file reports altogether, which
>> do not really belong to the unit tests IMHO.
>> Anyway, wrt encoding issues, I did face an issue some time ago due to a text
>> report file that was encoded in latin1 but opened as utf8, but I transcoded
>> the file since then.
>> The tests run fine on revision 371 (if you're in the CET zone).
>> Romain.
>> On 2 nov. 2012, at 21:25, Thomas <tledou...@gmail.com> wrote:
>>> Hi Ali,
>>> I just commited some corrections in r370.
>>> While doing my tests, I run into the same issue than you and I appears
>>> that some file texts used during tested where encoded in UTF-8 with BOM
>>> which make the test to fail.
>>> Could you please retry your build and let me know?
>>> Thanks in advance
>>> Thomas
> -- > You received this message because you are subscribed to the Google Groups "epubcheck" group.
> To post to this group, send email to epubcheck@googlegroups.com.
> To unsubscribe from this group, send email to epubcheck+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/epubcheck?hl=en.
indeed you were correct. I now calculate an UTC creation date which is
independent of the local timezone. The tests do now work even when I
pretend to be in India :-)
For the test part, the information in the text files is just an
extract of the validation report (the one we want to test). So the
values in the files need to be changed only when the information is
wrong (like for the creation date) and they have been useful to find
my error...
>> this is quite peculiar. Indeed, the [creation date] comes from the
>> time of the container.xml file in the zip container. From
>> http://docs.oracle.com/javase/1.4.2/docs/api/java/util/zip/ZipEntry.h...,
>> the time is supposed to be "the entry modification time in number of
>> milliseconds since the epoch". So for me this information should not
>> depend on the local timezone !!! I will look into that to understand
>> why this value varies.
> Well, the ZIP contains no info on the time zone where the ZIP entry was
> created, so the API returns the entry modification time by assuming that the
> entry was created in the same time zone as the current one.
> In other words, if you call ZipEntry#getTime on two different time zones,
> you will get two different values.
>> By the way, the text files in the test environment are not test
>> reports; they are just reference information (some interesting part of
>> the report) to be matched with the actual generated reports as part of
>> the unit tests.
> I know, but I believe that it does not make a lot of sense to test that the
> report matches for each single test method. The "unit" tests are quite
> focused ; testing the entire report info makes it a tad more dependent on
> non-related parts of epubcheck. Additionally, it's a bit more difficult to
> maintain since every time we will like to update the text report format we
> will need to re-generate the reports for all the test samples.
>>> I believe Ali's issue below was not an encoding issue. The problem is
>>> that
>>> the creation date field in the text file reports is time-zone sensitive.
>>> The
>>> fix would be to output a creation date relative to UTC when writing to
>>> the
>>> test reports or to simply get rid of the text file reports altogether,
>>> which
>>> do not really belong to the unit tests IMHO.
>>> Anyway, wrt encoding issues, I did face an issue some time ago due to a
>>> text
>>> report file that was encoded in latin1 but opened as utf8, but I
>>> transcoded
>>> the file since then.
>>> The tests run fine on revision 371 (if you're in the CET zone).
>>> Romain.
>>> On 2 nov. 2012, at 21:25, Thomas <tledou...@gmail.com> wrote:
>>>> Hi Ali,
>>>> I just commited some corrections in r370.
>>>> While doing my tests, I run into the same issue than you and I appears
>>>> that some file texts used during tested where encoded in UTF-8 with BOM
>>>> which make the test to fail.
>>>> Could you please retry your build and let me know?
>>>> Thanks in advance
>>>> Thomas
>> --
>> You received this message because you are subscribed to the Google Groups
>> "epubcheck" group.
>> To post to this group, send email to epubcheck@googlegroups.com.
>> To unsubscribe from this group, send email to
>> epubcheck+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/epubcheck?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "epubcheck" group.
> To post to this group, send email to epubcheck@googlegroups.com.
> To unsubscribe from this group, send email to
> epubcheck+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/epubcheck?hl=en.
On Fri, Nov 2, 2012 at 4:25 PM, Thomas <tledou...@gmail.com> wrote:
> Hi Ali,
> I just commited some corrections in r370.
> While doing my tests, I run into the same issue than you and I appears
> that some file texts used during tested where encoded in UTF-8 with BOM
> which make the test to fail.
> Could you please retry your build and let me know?
> Thanks in advance
> Thomas
> On Monday, October 29, 2012 4:54:16 PM UTC+1, lotia wrote:
>> Hi Romain,
>> I have now tried it on a CentOS 6.3 machine on which I have installed
>> maven 3.0.4 and I get the same output. It is downloading all the
>> required dependencies since it is creating a fresh local maven repo. I
>> have also tested with renaming my existing maven repo on my MacOS
>> 10.6.8 machine and it fails the same 10 unit tests as are failed
>> below.
>> --
>> Ali
> On Fri, Nov 2, 2012 at 4:25 PM, Thomas <tledou...@gmail.com> wrote:
>> Hi Ali,
>> I just commited some corrections in r370.
>> While doing my tests, I run into the same issue than you and I appears
>> that some file texts used during tested where encoded in UTF-8 with BOM
>> which make the test to fail.
>> Could you please retry your build and let me know?
>> Thanks in advance
>> Thomas
>> On Monday, October 29, 2012 4:54:16 PM UTC+1, lotia wrote:
>>> Hi Romain,
>>> I have now tried it on a CentOS 6.3 machine on which I have installed
>>> maven 3.0.4 and I get the same output. It is downloading all the
>>> required dependencies since it is creating a fresh local maven repo. I
>>> have also tested with renaming my existing maven repo on my MacOS
>>> 10.6.8 machine and it fails the same 10 unit tests as are failed
>>> below.
>>> --
>>> Ali
