Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-52669

IndexOutOfBoundsException after upgrade to 1.2.3

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have Artifact Resolver step configured like this:

      After upgrade to 1.2.3 (and also 1.2.4) I get this error when running job:

      failed to expand tokens for [Artifact cz.diribet:chystat:jar:executable:2.0.0-SNAPSHOT]
      java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
       at java.util.ArrayList.rangeCheck(ArrayList.java:657)
       at java.util.ArrayList.get(ArrayList.java:433)
       at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.getLatest(ReleasedVersionRangeResolver.java:181)
       at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.resolveVersionRange(ReleasedVersionRangeResolver.java:134)
       at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:370)
       at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
       at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
       at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
       at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
       at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308)
       at org.jvnet.hudson.plugins.repositoryconnector.aether.Aether.resolve(Aether.java:221)
       at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.download(ArtifactResolver.java:217)
       at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.perform(ArtifactResolver.java:154)
       at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
       at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
       at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
       at hudson.model.Build$BuildExecution.build(Build.java:206)
       at hudson.model.Build$BuildExecution.doRun(Build.java:163)
       at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
       at hudson.model.Run.execute(Run.java:1815)
       at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
       at hudson.model.ResourceController.execute(ResourceController.java:97)
       at hudson.model.Executor.run(Executor.java:429)
      ERROR: Failed to resolve artifact
      

      After downgrade to 1.1.3 everything works without problems.

       

        Attachments

          Activity

          Hide
          nirmunair Nirmal Kumar added a comment -

          Do we have any recent update on this issue? Looks the 1.2 version has some issues with resolving the artifacts.

          Show
          nirmunair Nirmal Kumar added a comment - Do we have any recent update on this issue? Looks the 1.2 version has some issues with resolving the artifacts.
          Hide
          justinm89 Justin M added a comment - - edited

          I am running into this in a scripted pipeline trying to resolve just one of my artifacts – I have 4 WAR files I am trying to download and deploy, all in the same Nexus repository and same group ID and version. 3 of them can be resolved just fine, but for whatever reason, the 4th one gets this same error, and it's really frustrating that it works for all but one of the applications.

           

          I am encountering this on both 1.2.3 and 1.2.4. I tried rolling all the way back to version 1.1.3, but that version does not offer pipeline support, which I need for what I'm trying to accomplish. I am calling the step like so:

          artifactResolver artifacts: [artifact(artifactId: "single-sign-on", extension: "war", groupId: "com.foo.bar", targetFileName: "sso.war", version: "15.0.0-SNAPSHOT")], releaseUpdatePolicy: 'always', snapshotUpdatePolicy: 'always', targetDirectory: '.'

           

          And receiving the following stacktrace:

          failed to expand tokens for [Artifact com.foo.bar:single-sign-on:war::15.0.0-SNAPSHOT]
           java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
           at java.util.ArrayList.rangeCheck(Unknown Source)
           at java.util.ArrayList.get(Unknown Source)
           at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.getLatest(ReleasedVersionRangeResolver.java:181)
           at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.resolveVersionRange(ReleasedVersionRangeResolver.java:134)
           at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:370)
           at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
           at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
           at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
           at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308)
           at org.jvnet.hudson.plugins.repositoryconnector.aether.Aether.resolve(Aether.java:221)
           at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.download(ArtifactResolver.java:217)
           at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.perform(ArtifactResolver.java:154)
           at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80)
           at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67)
           at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:51)
           at hudson.security.ACL.impersonate(ACL.java:290)
           at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:48)
           at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
           at java.util.concurrent.FutureTask.run(Unknown Source)
           at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
           at java.lang.Thread.run(Unknown Source)
          Show
          justinm89 Justin M added a comment - - edited I am running into this in a scripted pipeline trying to resolve just one of my artifacts – I have 4 WAR files I am trying to download and deploy, all in the same Nexus repository and same group ID and version. 3 of them can be resolved just fine, but for whatever reason, the 4th one gets this same error, and it's really frustrating that it works for all but one of the applications.   I am encountering this on both 1.2.3 and 1.2.4. I tried rolling all the way back to version 1.1.3, but that version does not offer pipeline support, which I need for what I'm trying to accomplish. I am calling the step like so: artifactResolver artifacts: [artifact(artifactId: "single-sign-on" , extension: "war" , groupId: "com.foo.bar" , targetFileName: "sso.war" , version: "15.0.0-SNAPSHOT" )], releaseUpdatePolicy: 'always' , snapshotUpdatePolicy: 'always' , targetDirectory: '.'   And receiving the following stacktrace: failed to expand tokens for [Artifact com.foo.bar:single-sign-on:war::15.0.0-SNAPSHOT] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.getLatest(ReleasedVersionRangeResolver.java:181) at org.jvnet.hudson.plugins.repositoryconnector.aether.ReleasedVersionRangeResolver.resolveVersionRange(ReleasedVersionRangeResolver.java:134) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:370) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308) at org.jvnet.hudson.plugins.repositoryconnector.aether.Aether.resolve(Aether.java:221) at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.download(ArtifactResolver.java:217) at org.jvnet.hudson.plugins.repositoryconnector.ArtifactResolver.perform(ArtifactResolver.java:154) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:51) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:48) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang. Thread .run(Unknown Source)
          Hide
          dennisl Dennis Lundberg added a comment -

          Justin M Does the problematic artifact have a released version in your repository?

          Do the successful artifacts have any released versions in your repository?

          Show
          dennisl Dennis Lundberg added a comment - Justin M Does the problematic artifact have a released version in your repository? Do the successful artifacts have any released versions in your repository?
          Hide
          justinm89 Justin M added a comment -

          Yes to both questions – I have found a workaround in that for this specific artifact I can simply use Powershell or wget to pull it down. Not ideal, but it will get the job done.

          Show
          justinm89 Justin M added a comment - Yes to both questions – I have found a workaround in that for this specific artifact I can simply use Powershell or wget to pull it down. Not ideal, but it will get the job done.
          Hide
          sgautrin Sébastien Gautrin added a comment - - edited

          I encountered the same issue recently with one artifact. I got multiple artifacts from a multi-module maven project that are released to nexus by another job, then several similar scripted pipeline jobs for deploying different artifacts, with all of them using an Artifact parameter with the same artifact configured.

          With one of them, I encounter this error (whether using the job parameter or a hardcoded version, the configured version in the step being overriden by the job parameter anyway according to the log “Overriding configured version ... with version ... from build parameter”).

          The IndexOutOfBoundException itself comes from a mistake in the code in ReleasedVersionRangeResolver : before accessing the first entry in vs collection, there is a check on versions collection instead of the filtered vs collection; with a test on the filtered collection, the method would return null instead of raising an exception, though this would possibly raise an exception down the line anyway. In my case and the OP's though, we should not even enter this method, as we specify a single version and not a version range: I've yet to identify why in this case I end up there, while I do not with other artifacts.

          Edit: I might have found the cause: in the final pom of my artifact, I do have a dependency defined as a range, and the corresponding artifact is not present on the same repository (the artifact I want is on a private repository, the ranged dependency is on central); I cannot confirm yet this is the cause, but it seems likely considering the error occurs within Aether.resolve and the dependencies collection.

          Vlastimil Dolejš (and Justin M) do you also happen to have a dependency with a version range on the artifact you encounter the error with? (check the pom.xml of the artifact version on your repository)

          However, considering this plugin, we should probably ignore dependencies or the requested artifact, should we not?

          Show
          sgautrin Sébastien Gautrin added a comment - - edited I encountered the same issue recently with one artifact. I got multiple artifacts from a multi-module maven project that are released to nexus by another job, then several similar scripted pipeline jobs for deploying different artifacts, with all of them using an Artifact parameter with the same artifact configured. With one of them, I encounter this error (whether using the job parameter or a hardcoded version, the configured version in the step being overriden by the job parameter anyway according to the log “Overriding configured version ... with version ... from build parameter”). The IndexOutOfBoundException itself comes from a mistake in the code in ReleasedVersionRangeResolver : before accessing the first entry in vs collection, there is a check on versions collection instead of the filtered vs collection; with a test on the filtered collection, the method would return null instead of raising an exception, though this would possibly raise an exception down the line anyway. In my case and the OP's though, we should not even enter this method, as we specify a single version and not a version range: I've yet to identify why in this case I end up there, while I do not with other artifacts. Edit: I might have found the cause: in the final pom of my artifact, I do have a dependency defined as a range, and the corresponding artifact is not present on the same repository (the artifact I want is on a private repository, the ranged dependency is on central); I cannot confirm yet this is the cause, but it seems likely considering the error occurs within Aether.resolve and the dependencies collection. Vlastimil Dolejš (and Justin M ) do you also happen to have a dependency with a version range on the artifact you encounter the error with? (check the pom.xml of the artifact version on your repository) However, considering this plugin, we should probably ignore dependencies or the requested artifact, should we not?
          Hide
          vlastimil_dolejs Vlastimil Dolejš added a comment -

          I can confirm that the problem is related to the version range. In my case, I don't have direct dependency with version range but there is some transitive dependency in my dependency tree that has version declared as a range. 

          I have cloned the plugin source and written unit test for my artifact so I know the details. The problematic dependency in my case is org.webjars.npm:js-tokens:jar:[1.0.1,2)

          This dependency can be resolved and there are these versions in repository: [1.0.0, 1.0.1, 2.0.0, 3.0.0, 3.0.1, 3.0.2, 4.0.0].

          The problematic part of code is in

          ReleasedVersionRangeResolver#resolveVersionRange

          on lines 134 and 135.

          The 3.0.2 and 4.0.0 is picked as the 

          versionsAndUpToDates.latestCandidates

          and

          versionsAndUpToDates.releaseCandidates

          which is then passed to 

          getLatest()
          

          but none of these versions satisfy version range constraint which is [1.0.1,2).

          So I think there are 2 problems.

          1/ The getLatest() method should return null instead of throwing exception if it won't match any version with the version range.
          2/ I think we should pass versionsAndUpToDates.versions instead of versionsAndUpToDates.latestCandidates and releaseCandidates to the getLatest() method on lines 134 and 135.

          I have created pull request for the first problem: https://github.com/jenkinsci/repository-connector-plugin/pull/37
          This will completely resolve the problem because resolving transitive dependencies is not necessary.

          Show
          vlastimil_dolejs Vlastimil Dolejš added a comment - I can confirm that the problem is related to the version range. In my case, I don't have direct dependency with version range but there is some transitive dependency in my dependency tree that has version declared as a range.  I have cloned the plugin source and written unit test for my artifact so I know the details. The problematic dependency in my case is org.webjars.npm:js-tokens:jar:[1.0.1,2) This dependency can be resolved and there are these versions in repository: [1.0.0, 1.0.1, 2.0.0, 3.0.0, 3.0.1, 3.0.2, 4.0.0] . The problematic part of code is in ReleasedVersionRangeResolver#resolveVersionRange on lines 134 and 135. The 3.0.2 and 4.0.0 is picked as the  versionsAndUpToDates.latestCandidates and versionsAndUpToDates.releaseCandidates which is then passed to  getLatest() but none of these versions satisfy version range constraint which is [1.0.1,2). So I think there are 2 problems. 1/ The getLatest() method should return null instead of throwing exception if it won't match any version with the version range. 2/ I think we should pass versionsAndUpToDates.versions instead of versionsAndUpToDates.latestCandidates and releaseCandidates to the getLatest() method on lines 134 and 135. I have created pull request for the first problem: https://github.com/jenkinsci/repository-connector-plugin/pull/37 This will completely resolve the problem because resolving transitive dependencies is not necessary.
          Hide
          jgangemi Jae Gangemi added a comment -

          fixed in 1.2.6

          Show
          jgangemi Jae Gangemi added a comment - fixed in 1.2.6
          Hide
          justinm89 Justin M added a comment -

          Just installed and tested with version 1.2.6 and can confirm that it's working to resolve my artifact. Thanks, Jae.

          Show
          justinm89 Justin M added a comment - Just installed and tested with version 1.2.6 and can confirm that it's working to resolve my artifact. Thanks, Jae.

            People

            • Assignee:
              jgangemi Jae Gangemi
              Reporter:
              vlastimil_dolejs Vlastimil Dolejš
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: