title: Cannot resolve Artifact by Build Number or LATEST when copied to another repository
body: <p>We are having difficulties with our use of the <em>Artifactory Plug-in for Jenkins</em> when specifying <strong>Resolution Details | Resolved Artifacts (requires Artifactory Pro)</strong> (I will refer to this value as the <em>Artifactory-query-string</em>).</p>
  <p>Our use of Artifactory in this case is to pull an existing module (a single ZIP file in Artifactory), and we wish to retrieve that specific module with a <em>specific build number</em> or the abstract request for '<em>LATEST</em>' build.</p>
  <p>We can get the result that we want when the module / artifact that we want exists in only one repository.  But after a given BUILD # of a module has been 'promoted' (via simple copy operation in Artifactory) then we are not able to find the 'promoted' artifact in the Repository it was copied to.</p>
  <h3>Tools / Versions</h3>
  <ul>
  <li>Jenkins (2.7.2)</li>
  <li>Artifactory Pro (4.11.2)</li>
  <li>Artifactory Plug-in for Jenkins (2.6.0)</li>
  <li>Generic Package Type with the 'simple-default' layout in Artifactory</li>
  </ul>
  <h3>Background</h3>
  <p>Recently we have introduced the Jenkins Build # as both a property for the artifact and as part of the artifact file name.</p>
  <p>The only source of information that we have been able to find with details about this 'Artifactory-query-string' is via the Help information available via the Question Mark icon located next to the input area.</p>
  <p>Our interpretation of this Help text indicates:</p>
  <ul>
  <li>If one wants to retrieve by <strong>build_number</strong> (or 'LATEST') then the <strong>build_name</strong> value MUST also be specified, in other words these two values are mutually dependent</li>
  </ul>
  <h2>Working Case</h2>
  <p>When using this capability in this manner (in one repository only - called <strong>DEV</strong>), everything works as expected.  We are able to successfully fill a request for 'LATEST' or a specific Build Number using the <strong>build_number</strong> parameter, as long as we also specify the <strong>build_name</strong>.</p>
  <p><em>Artifactory tree</em></p>
  <ul>
  <li><strong>DEV</strong> (repository)
  <ul>
  <li><strong>somePath</strong> (path)
  <ul>
  <li><strong>myApplication-build-100.zip</strong>       build_number: <strong>100</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  <li><strong>myApplication-build-101.zip</strong>       build_number: <strong>101</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  <li><strong>myApplication-build-102.zip</strong>       build_number: <strong>102</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  </ul>
  </li>
  </ul>
  </li>
  </ul>
  <p><em>Artifactory-query-string</em><br />
  <code>$DEV:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=&gt;.\someFolder</code></p>
  <p>This <em>Artifactory-query-string</em> will properly return the single artifact: <code>myApplication-build-102.zip</code></p>
  <h2>Failing Case</h2>
  <p>However after one of these builds is 'promoted' to another repository such as <strong>QA</strong> via a simple COPY operation in Artifactory, we cannot figure out how to leverage this same capability against the <strong>QA</strong> repository where the artifact was just copied ('promoted').  In other words, we cannot 'find' the copied / 'promoted' artifact in the repository where it was copied to.</p>
  <p><em>Artifactory tree</em></p>
  <ul>
  <li><strong>DEV</strong> (repository)
  <ul>
  <li><strong>somePath</strong> (path)
  <ul>
  <li><strong>myApplication-build-100.zip</strong>       build_number: <strong>100</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  <li><strong>myApplication-build-101.zip</strong>       build_number: <strong>101</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  <li><strong>myApplication-build-102.zip</strong>       build_number: <strong>102</strong>   build_name: <strong>myJenkinsBuildJob</strong></li>
  </ul>
  </li>
  </ul>
  </li>
  <li><strong>QA</strong> (repository)
  <ul>
  <li><strong>somePath</strong> (path)
  <ul>
  <li><strong>myApplication-build-102.zip</strong>       build_number: <strong>102</strong>   build_name: <strong>myJenkinsBuildJob</strong> (copied / 'promoted' from DEV repository)</li>
  </ul>
  </li>
  </ul>
  </li>
  </ul>
  <p><em>Artifactory-query-string</em><br />
  Using the same 'Artifactory-query-string' as before but specifying the <strong>QA</strong> repository rather than <strong>DEV</strong></p>
  <p><code>$QA:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=&gt;.\someFolder</code></p>
  <p>then the Artifactory plug-in for Jenkins never returns / finds anything:</p>
  <pre><code>Jenkins Artifactory Plugin version: 2.6.0
  Beginning to resolve Build Info dependencies.
  Finished resolving Build Info dependencies.
  Beginning to resolve Build Info build dependencies.
  Dependency on build [myJenkinsBuildJob], number [LATEST], pattern [QA:somePath/myApplication*.zip] - [0] results found.
  </code></pre>
  <p>An interesting note is that if we delete the original artifact in the <strong>DEV</strong> repository, then the query against <strong>QA</strong> works correctly.</p>
  <p>The observed behavior seems to suggest that a given artifact (based on the filename, build # and build name) can only be located / queried (resolved) in one repository and that if you copy an artifact to another repository it will be 'hidden' or ignored for such a query.</p>
  <p>This is not the behavior that we expected.  We expected that each repository is separate from the others and that a query against one repository should NOT take into account anything about any other repositories -- and that we should be able to locate / find / resolve a copied module in the repository it was copied to.</p>
  <p>Can anyone suggest what am I missing here?  Are my expectations wrong?</p>