Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-5629

ClosedChannelException from DefaultUpdateCheckManager.read

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.5.0-alpha-1, 3.5.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows 7, Java 7 updated 25

      Description

      I ran a build in debug mode (mvn -X) and noticed the following bug (repeatedly):

      [DEBUG] Error releasing shared lock for resolution tracking file: C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
      java.nio.channels.ClosedChannelException
      	at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
      	at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
      	at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
      	at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
      	at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
      	at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
      	at org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
      	at org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
      	at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
      	at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
      	at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
      	at org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
      	at org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
      	at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
      	at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
      	at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
      	at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
      	at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
      	at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
      	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
      	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
      	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
      	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
      	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
      	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
      	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
      	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
      	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
      	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
      	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
      	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
      	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
      	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
      	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
      	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
      

      I traced the bug to the DefaultUpdateCheckManager.read method. Line 396 is releasing a FileLock, but the FileInputStream has already been closed by Line 381.

        Issue Links

          Activity

          Hide
          jvanzyl Jason van Zyl added a comment -

          Do you have a little sample project you provide or what you ran so we can reproduce this?

          Show
          jvanzyl Jason van Zyl added a comment - Do you have a little sample project you provide or what you ran so we can reproduce this?
          Hide
          awhitford Anthony Whitford added a comment -

          It looks like it is the site phase that causes this error: mvn -X site
          You can use this project to replicate the issue: https://github.com/awhitford/lombok.maven

          Also note that I was able to reproduce the issue on a Mac too, so this isn't limited to Windows.
          And I was not able to replicate the issue with Maven 3.0.5, so this seems limited to 3.2.1.

          Show
          awhitford Anthony Whitford added a comment - It looks like it is the site phase that causes this error: mvn -X site You can use this project to replicate the issue: https://github.com/awhitford/lombok.maven Also note that I was able to reproduce the issue on a Mac too, so this isn't limited to Windows. And I was not able to replicate the issue with Maven 3.0.5, so this seems limited to 3.2.1.
          Hide
          jvanzyl Jason van Zyl added a comment -

          Possibly caused by a different version of the site plugin, and not Maven itself?

          Show
          jvanzyl Jason van Zyl added a comment - Possibly caused by a different version of the site plugin, and not Maven itself?
          Hide
          awhitford Anthony Whitford added a comment -

          Who owns DefaultUpdateCheckManager.java? Is that not part of Maven?

          I'm pretty sure that the issue is that the code is calling lock.release() for a lock related to a closed FileInputStream. It is like a double-close. The Javadoc for FileLock.release states that it will throw a ClosedChannelException if the channel that was used to acquire this lock is no longer open.

          I suspect that lines 390 to 416 are not necessary thanks to lines 379 to 382.

          Show
          awhitford Anthony Whitford added a comment - Who owns DefaultUpdateCheckManager.java ? Is that not part of Maven? I'm pretty sure that the issue is that the code is calling lock.release() for a lock related to a closed FileInputStream . It is like a double-close. The Javadoc for FileLock.release states that it will throw a ClosedChannelException if the channel that was used to acquire this lock is no longer open. I suspect that lines 390 to 416 are not necessary thanks to lines 379 to 382.
          Hide
          awhitford Anthony Whitford added a comment -

          I can recreate with Java 8 Update 5 too. I think this should be reopened.

          Show
          awhitford Anthony Whitford added a comment - I can recreate with Java 8 Update 5 too. I think this should be reopened.
          Hide
          jvanzyl Jason van Zyl added a comment -

          If you have a test case that I can reproduce it then it can be reopened.

          Show
          jvanzyl Jason van Zyl added a comment - If you have a test case that I can reproduce it then it can be reopened.
          Hide
          public@ecopatz.de Olaf Krische added a comment -

          I can reproduce it. I have two projects X and Y (uploaded as xy.tar.gz)

          krische@ds0093:/tmp$ tar xvzf xy.tar.gz 
          X/
          X/pom.xml
          X/src/
          X/src/main/
          X/src/main/java/
          X/src/main/java/Application.java
          X/src/main/resources/
          Y/
          Y/pom.xml
          Y/src/
          Y/src/main/
          Y/src/main/java/
          Y/src/main/java/MavenService.java
          Y/src/main/resources/
          cd Y
          mvn -U clean compile exec:java -Dexec.mainClass="MavenService"
          

          I use java8, linux, mvn 3.2.1 and project Y uses maven-embedder for maven 3.2.1 and it does then a "versions:display-dependency-updates" on the project X.

          Hope it helps.

          Show
          public@ecopatz.de Olaf Krische added a comment - I can reproduce it. I have two projects X and Y (uploaded as xy.tar.gz) krische@ds0093:/tmp$ tar xvzf xy.tar.gz X/ X/pom.xml X/src/ X/src/main/ X/src/main/java/ X/src/main/java/Application.java X/src/main/resources/ Y/ Y/pom.xml Y/src/ Y/src/main/ Y/src/main/java/ Y/src/main/java/MavenService.java Y/src/main/resources/ cd Y mvn -U clean compile exec:java -Dexec.mainClass= "MavenService" I use java8, linux, mvn 3.2.1 and project Y uses maven-embedder for maven 3.2.1 and it does then a "versions:display-dependency-updates" on the project X. Hope it helps.
          Hide
          public@ecopatz.de Olaf Krische added a comment -

          (a simple check on "lock.isValid()" before releasing it would fix it)

          $ touch /tmp/bla
          
          public static void main(String[] args) throws IOException {
            File touchfile = new File("/tmp/bla");
            FileInputStream stream = new FileInputStream( touchfile );
            FileChannel channel = stream.getChannel();
            FileLock lock = channel.lock( 0, channel.size(), true );
            System.err.println("before stream is closed: "+lock.isValid());
            stream.close();
            System.err.println("after stream is closed: "+lock.isValid());
            // will raise the exception, bcs stream is closed
            lock.release();
          }
          
          Show
          public@ecopatz.de Olaf Krische added a comment - (a simple check on "lock.isValid()" before releasing it would fix it) $ touch /tmp/bla public static void main( String [] args) throws IOException { File touchfile = new File( "/tmp/bla" ); FileInputStream stream = new FileInputStream( touchfile ); FileChannel channel = stream.getChannel(); FileLock lock = channel.lock( 0, channel.size(), true ); System .err.println( "before stream is closed: " +lock.isValid()); stream.close(); System .err.println( "after stream is closed: " +lock.isValid()); // will raise the exception, bcs stream is closed lock.release(); }
          Hide
          awhitford Anthony Whitford added a comment -

          Olaf, your idea to check lock.isValid() might be the safest approach to keep the finally handler generic in case the try changes over time, so the DefaultUpdateCheckManager finally handler could look like:

          if ( lock != null && lock.isValid() )
          {
              try
              {
                  lock.release();
              }
              catch ( IOException e )
              {
                  getLogger().debug( "Error releasing shared lock for resolution tracking file: " + touchfile,
                      e );
              }
          }
          

          My comment is advocating that the whole finally handler (lines 390 through to 416) be removed because it isn't necessary; the finally handler on lines 379 through 382 is all the necessary cleanup – line 381 closes everything.

          As I mentioned, my project on github demonstrates the problem as long as you run the site phase with debug (-X).

          Show
          awhitford Anthony Whitford added a comment - Olaf, your idea to check lock.isValid() might be the safest approach to keep the finally handler generic in case the try changes over time, so the DefaultUpdateCheckManager finally handler could look like: if ( lock != null && lock.isValid() ) { try { lock.release(); } catch ( IOException e ) { getLogger().debug( "Error releasing shared lock for resolution tracking file: " + touchfile, e ); } } My comment is advocating that the whole finally handler (lines 390 through to 416) be removed because it isn't necessary ; the finally handler on lines 379 through 382 is all the necessary cleanup – line 381 closes everything. As I mentioned, my project on github demonstrates the problem as long as you run the site phase with debug ( -X ).
          Hide
          trex58 Tony Reix added a comment -

          Hi
          What is the status of this issue today ?
          I was working on the port of Falcon on PPC64 when it appeared. I'm now blocked.
          First, I was on RHEL7/PPC64BE: this Maven error was not there, and I've been able to compile and run tests, with IBM JVM v1.6 .
          Then, I moved to Ubuntu/PPC64LE, with IBM JVM 1.7, and the issue appeared.
          I then tried on Ubuntu/x86_64, with IBM JVM and then Oracle JVM, v1.7, and the issue was there too.
          I gonna try with Java v1.6 on Ubuntu/x86_64 asap.

          Traces show the issue when using -X only.

          Example of traces, on Ubuntu/x86_64:

          [DEBUG] Determining update check for artifact asm:asm (/home/reixt/.m2/repository/asm/asm/maven-metadata-DN_M2_Repo.xml) from DN_M2_Repo (http://www.datanucleus.org/downloads/maven2/)
          [DEBUG] Searching for DN_M2_Repo.maven-metadata-DN_M2_Repo.xml.lastUpdated in resolution tracking file.
          [DEBUG] Reading resolution-state from: /home/reixt/.m2/repository/asm/asm/resolver-status.properties
          [DEBUG] Error releasing shared lock for resolution tracking file: /home/reixt/.m2/repository/asm/asm/resolver-status.properties
          java.nio.channels.ClosedChannelException
          at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:70)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)

          Show
          trex58 Tony Reix added a comment - Hi What is the status of this issue today ? I was working on the port of Falcon on PPC64 when it appeared. I'm now blocked. First, I was on RHEL7/PPC64BE: this Maven error was not there, and I've been able to compile and run tests, with IBM JVM v1.6 . Then, I moved to Ubuntu/PPC64LE, with IBM JVM 1.7, and the issue appeared. I then tried on Ubuntu/x86_64, with IBM JVM and then Oracle JVM, v1.7, and the issue was there too. I gonna try with Java v1.6 on Ubuntu/x86_64 asap. Traces show the issue when using -X only. Example of traces, on Ubuntu/x86_64: [DEBUG] Determining update check for artifact asm:asm (/home/reixt/.m2/repository/asm/asm/maven-metadata-DN_M2_Repo.xml) from DN_M2_Repo ( http://www.datanucleus.org/downloads/maven2/ ) [DEBUG] Searching for DN_M2_Repo.maven-metadata-DN_M2_Repo.xml.lastUpdated in resolution tracking file. [DEBUG] Reading resolution-state from: /home/reixt/.m2/repository/asm/asm/resolver-status.properties [DEBUG] Error releasing shared lock for resolution tracking file: /home/reixt/.m2/repository/asm/asm/resolver-status.properties java.nio.channels.ClosedChannelException at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:70) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
          Hide
          trex58 Tony Reix added a comment -

          I've tried to use IBM JVM 1.6 for compiling Falcon on Ubuntu/x86_64.
          I've got the same ClosedChannelException, several times (24 !).
          Compilation ends with an error.

          export HADOOP_VERSION=2.4.1
          export HADOOP_PROFILE=hadoop-2
          export OOZIE_VERSION=4.0.1
          mvn -X compile -P $HADOOP_PROFILE -Dhadoop.version=$HADOOP_VERSION -Doozie.version=$OOZIE_VERSION -Doozie.forcebuild=false -DskipTests

          ...
          [DEBUG] Determining update check for artifact asm:asm (/home/reixt/.m2/repository/asm/asm/maven-metadata-central.xml) from central (http://repo1.maven.org/maven2)
          [DEBUG] Searching for central.maven-metadata-central.xml.lastUpdated in resolution tracking file.
          [DEBUG] Reading resolution-state from: /home/reixt/.m2/repository/asm/asm/resolver-status.properties
          [DEBUG] Error releasing shared lock for resolution tracking file: /home/reixt/.m2/repository/asm/asm/resolver-status.properties
          java.nio.channels.ClosedChannelException
          at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:47)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
          at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)

          ...

          [INFO] Apache Falcon Oozie EL Extension .................. FAILURE [ 26.935 s]
          [INFO] Apache Falcon Embedded Hadoop - Test Cluster ...... SKIPPED
          ....
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD FAILURE
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 17:52 min
          [INFO] Finished at: 2014-10-20T10:18:30-05:00
          [INFO] Final Memory: 38M/181M
          [INFO] ------------------------------------------------------------------------
          [ERROR] Failed to execute goal on project falcon-oozie-el-extension: Could not resolve dependencies for project org.apache.falcon:falcon-oozie-el-extension:jar:0.5-incubating: Could not find artifact org.apache.oozie:oozie-core:jar:4.0.1-falcon in central (http://repo1.maven.org/maven2) -> [Help 1]
          org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project falcon-oozie-el-extension: Could not resolve dependencies for project org.apache.falcon:falcon-oozie-el-extension:jar:0.5-incubating: Could not find artifact org.apache.oozie:oozie-core:jar:4.0.1-falcon in central (http://repo1.maven.org/maven2)

          Show
          trex58 Tony Reix added a comment - I've tried to use IBM JVM 1.6 for compiling Falcon on Ubuntu/x86_64. I've got the same ClosedChannelException, several times (24 !). Compilation ends with an error. export HADOOP_VERSION=2.4.1 export HADOOP_PROFILE=hadoop-2 export OOZIE_VERSION=4.0.1 mvn -X compile -P $HADOOP_PROFILE -Dhadoop.version=$HADOOP_VERSION -Doozie.version=$OOZIE_VERSION -Doozie.forcebuild=false -DskipTests ... [DEBUG] Determining update check for artifact asm:asm (/home/reixt/.m2/repository/asm/asm/maven-metadata-central.xml) from central ( http://repo1.maven.org/maven2 ) [DEBUG] Searching for central.maven-metadata-central.xml.lastUpdated in resolution tracking file. [DEBUG] Reading resolution-state from: /home/reixt/.m2/repository/asm/asm/resolver-status.properties [DEBUG] Error releasing shared lock for resolution tracking file: /home/reixt/.m2/repository/asm/asm/resolver-status.properties java.nio.channels.ClosedChannelException at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:47) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159) at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148) ... [INFO] Apache Falcon Oozie EL Extension .................. FAILURE [ 26.935 s] [INFO] Apache Falcon Embedded Hadoop - Test Cluster ...... SKIPPED .... [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 17:52 min [INFO] Finished at: 2014-10-20T10:18:30-05:00 [INFO] Final Memory: 38M/181M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project falcon-oozie-el-extension: Could not resolve dependencies for project org.apache.falcon:falcon-oozie-el-extension:jar:0.5-incubating: Could not find artifact org.apache.oozie:oozie-core:jar:4.0.1-falcon in central ( http://repo1.maven.org/maven2 ) -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project falcon-oozie-el-extension: Could not resolve dependencies for project org.apache.falcon:falcon-oozie-el-extension:jar:0.5-incubating: Could not find artifact org.apache.oozie:oozie-core:jar:4.0.1-falcon in central ( http://repo1.maven.org/maven2 )
          Hide
          trex58 Tony Reix added a comment -

          For my projects, dealing with Hadoop, I always use Maven v3.2.1 .

          $ mvn --version
          Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T12:37:52-05:00)
          Maven home: /opt/apache-maven-3.2.1

          Show
          trex58 Tony Reix added a comment - For my projects, dealing with Hadoop, I always use Maven v3.2.1 . $ mvn --version Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T12:37:52-05:00) Maven home: /opt/apache-maven-3.2.1
          Hide
          trex58 Tony Reix added a comment -

          I've opened a new JIRA: http://jira.codehaus.org/browse/MNG-5703 .

          Show
          trex58 Tony Reix added a comment - I've opened a new JIRA: http://jira.codehaus.org/browse/MNG-5703 .
          Hide
          schulte77 Christian Schulte added a comment -
          Show
          schulte77 Christian Schulte added a comment - Corrected in 7cd7bd8648dd4755f4ef1b09e031f03d8bdc59b2
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in maven-3.x #1160 (See https://builds.apache.org/job/maven-3.x/1160/)
          MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: rev 7cd7bd8648dd4755f4ef1b09e031f03d8bdc59b2)

          • maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in maven-3.x #1160 (See https://builds.apache.org/job/maven-3.x/1160/ ) MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: rev 7cd7bd8648dd4755f4ef1b09e031f03d8bdc59b2) maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in maven-3.x #1161 (See https://builds.apache.org/job/maven-3.x/1161/)
          MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: rev 792a9b8eaae2345b6dd0429d8b90d0358f48fa24)

          • maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in maven-3.x #1161 (See https://builds.apache.org/job/maven-3.x/1161/ ) MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: rev 792a9b8eaae2345b6dd0429d8b90d0358f48fa24) maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
          Hide
          stephenc Stephen Connolly added a comment -

          Maven 3.4.0 has been dropped. See this thread for more details.

          This issue will need to be re-scheduled for a Maven release in the (hopefully near) future.

          Show
          stephenc Stephen Connolly added a comment - Maven 3.4.0 has been dropped. See this thread for more details. This issue will need to be re-scheduled for a Maven release in the (hopefully near) future.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Jenkins build maven-3.x #1497 (See https://builds.apache.org/job/maven-3.x/1497/)
          MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=ca1179ce6ab6ed78fe755e2b97f7e0c01ea91361)

          • (edit) maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Jenkins build maven-3.x #1497 (See https://builds.apache.org/job/maven-3.x/1497/ ) MNG-5629 ClosedChannelException from DefaultUpdateCheckManager.read (schulte: http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=ca1179ce6ab6ed78fe755e2b97f7e0c01ea91361 ) (edit) maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java

            People

            • Assignee:
              schulte77 Christian Schulte
              Reporter:
              awhitford Anthony Whitford
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development