[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

["Simon Spero (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071324#comment-16071324 ] 

Simon Spero commented on COMPRESS-413:
--------------------------------------

I will  try a few sample builds to to check for  effect on build  time to
completion. If there's no important effect then this is fine; if it is
important then I may reorder the matrix.

I will submit an issue with a patch for changes that belong in parent
(unless parent is now in git.

The indicated  errors are the ones I expect to see with the final 9-ea. The
illegal access from the mocker in ZCompressorInputStreamTest is reduced to
a warning in RC, which is acceptable for testing and can be left for now.

The timestamp behavior is an error, but I am not sure if the new behavior
in jdk 9 is wrong and needs a workaround, or right and needs a workaround,
or is wrong but should be ignored as it seems to be a deliberate decision
to not hack around DOS  years after 2099.  Adapting to follow jdk behavior
seems to be the best bet for now, since the error is being detected in a
situation where there are correct timestamps.

I could file an issue in this for jdk core-libs but I think this might be
scheduled for a fix in jdk 49).

(My current thinking is to deprecate the use of DOS times  for creating
archives after that year, and to ensure that any consent forms for
replicating or storing any simulation of what "I" "perceive" as "my"
"consciousness" stipulate that no such contents may be stored in zip
format.

It will go next to the clause refusing permission to transform me into a
brain in a vat unless it's VAT 69)


On Jun 30, 2017 7:05 PM, "Gary Gregory (JIRA)" <ji...@apache.org> wrote:


     [ https://issues.apache.org/jira/browse/COMPRESS-413?page=
com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Gregory resolved COMPRESS-413.
-----------------------------------
    Resolution: Fixed

Thank you for the PR. Patch applied except for the removal of Oracle 7 and
8 from the Travis build.

Please verify and close or continue.

I only see 1 error and one failure now instead of a bunch:

{noformat}
Failed tests:
  X5455_ExtendedTimestampTest.testSampleFile:185
expected:<[2105-01-01/00:00:02]
+0000> but was:<[1968-11-24/17:31:45] +0000>
Tests in error:
  ZCompressorInputStreamTest.testFailsToCreateZCompressorInputStreamAndThrowsIOException
╗

Tests run: 842, Failures: 1, Errors: 1, Skipped: 4
{noformat}

phase.
tests.
retested; this time with
run tests with coverage during the build phase.
if the service is unreachable, so forks that don't have jacoco enabled
won't always have their builds fail.
properly at the moment, so installing a jdk7 doesn't work properly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


> Travis build redundantly repeats compilation and tests redundantly
> ------------------------------------------------------------------
>
>                 Key: COMPRESS-413
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-413
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Build
>    Affects Versions: 1.14
>         Environment: Travis
>            Reporter: Simon Spero
>            Priority: Minor
>              Labels: CI
>             Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if the service is unreachable, so forks that don't have jacoco enabled won't always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)