[JIRA] (JENKINS-52669) IndexOutOfBoundsException after upgrade to 1.2.3

2019-03-15 Thread s.gaut...@orange.fr (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Sébastien Gautrin edited a comment on  JENKINS-52669  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: IndexOutOfBoundsException after upgrade to 1.2.3   
 

  
 
 
 
 

 
 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|https://github.com/jenkinsci/repository-connector-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/repositoryconnector/aether/ReleasedVersionRangeResolver.java] : 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_dolejs]  (and [~justinm89])  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?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 
   

[JIRA] (JENKINS-52669) IndexOutOfBoundsException after upgrade to 1.2.3

2019-03-13 Thread s.gaut...@orange.fr (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Sébastien Gautrin edited a comment on  JENKINS-52669  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: IndexOutOfBoundsException after upgrade to 1.2.3   
 

  
 
 
 
 

 
 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|https://github.com/jenkinsci/repository-connector-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/repositoryconnector/aether/ReleasedVersionRangeResolver.java] : 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  though , 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_dolejs] 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?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 
  

[JIRA] (JENKINS-52669) IndexOutOfBoundsException after upgrade to 1.2.3

2019-03-13 Thread s.gaut...@orange.fr (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Sébastien Gautrin commented on  JENKINS-52669  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: IndexOutOfBoundsException after upgrade to 1.2.3   
 

  
 
 
 
 

 
 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 though, 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.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.