I don't understand which problem you are trying to solve. You are copying the resolved artifact into `"$buildDir/download/artifacts"`. But why should it originally be resolved from there?

Also note that artifacts resolved from repositories with a `file:` URL aren't cached. I suppose that's why the path starts with `C:\Repos\` rather than `~/.gradle`.

Let's see if I can explain it a little better. We are using gradle for our Continuous Delivery pipeline in Jenkins, it is modeled after your Continuous Delivery talk and presentation based on the toDo project on GitHub. The first stage is 'gradle publish', the src is built, packaged, and uploaded to the repository with a release version ie. 1.0.2 (example project 'bulk-update-osgi.gradle').

The next stage is deployment to the lower environments where we would like gradle to download the artifact from the repository (downloadOsgiBundle.gradle) and execute deployment tasks against it. Since it's a pipeline it's simple enough to copy the old workspace and use the built artifact from the first stage or just create a project level dependency between build and deploy. However that is not what we are looking for, we want to be able to choose which version to deploy when it goes to the stage and production environments along a few other requirements like being able to deploy artifacts to developer sandboxes on the fly for troubleshooting.

In order to do that without rebuilding from src it makes sense to download the artifact from the repo and then execute deployment. That's where the issue is occurring, normally when a dependency is defined like in downloadOsgiBundle.gradle, gradle hits the repo, downloads the artifact, and everything is great but, for some reason in this setup, it's not downloading the artifact. Instead it's just resolving the configuration to $buildDir/distributions/ and not downloading the artifact from the repo.

Let me know if you need any other information.

Can you show the repository declaration(s)?

repositories {
mavenLocal()
maven

maven

maven

maven

maven

maven

maven

mavenCentral()
maven {
url "http://XXXXXXX/snilabs/libs-releases"
credentials {
username = 'deployer'
password = 'XXXXXXX'
}
}

The artifacts we need should be downloaded from "[1]http://XXXXXXX/snilabs/libs-releases"
----------------------------------------------------------------------------------------
[1] http://XXXXXXX/snilabs/libs-releases

Can you try with the latest Gradle version? If I'm not mistaken, there used to be a bug where an external dependency whose group, name, and version matched those of a local project was resolved as a project dependency, and I think it has meanwhile been fixed.

No luck, I tried deleting all the cache and using Gradle 1.11-rc-1.

That does sound like the issue I am having though. Is there a workaround that might you know of?

The closest I could find is: [1]http://forums.gradle.org/gradle/topic...

However, this is said to be fixed. Will have to investigate further. What happens when you set the dependency version to something other than `project.version` (assuming that other version exists in the repo)? And what happens when you temporarily change `project.version` in `fetchDeployArchives.doFirst

`? Could try the same with `project.group`.
----------------------------------------------------------------------------------------
[1] http://forums.gradle.org/gradle/topics/unable_to_resolve_detached_configuration_with_ourself_in_it

Manually using a version did not work, it still tries to resolve it from $buildDir/distributions.

deployCq group: project.group, name: archivePkg.baseName, version: '2.2.166', ext: 'zip'

The fetchDeployArchives task always shows UP-TO-DATE so the doFirst block changes do not run.

fetchDeployArchives.doFirst {
project.version = '2.2.165'
project.group = 'com.asdf'
}

-----------------------------
StdOut
-----------------------------
:buildSrc:build UP-TO-DATE
Loading configuration for environment 'DEV'.
Using Release Bundle com.scrippsnetworks.wcm:bulkupdate-osgi:2.2.166 for Deployment Config
PATH:C:\Repos\fnr-imp\bulkupdate-osgi\build\distributions\bulkupdate-osgi-2.2.166.zip
Using Release Bundle com.scrippsnetworks.imp.fnr:imp-osgi:2.2.166 for Deployment Config
PATH:C:\Repos\fnr-imp\imp-osgi\build\distributions\imp-osgi-2.2.166.zip
:bulkupdate:clean UP-TO-DATE
:bulkupdate-osgi:clean UP-TO-DATE
:common:clean UP-TO-DATE
:etl:clean UP-TO-DATE
:imp-osgi:clean UP-TO-DATE
:ws:clean UP-TO-DATE
:bulkupdate-osgi:fetchDeployArchives UP-TO-DATE
:bulkupdate-osgi:cqDeploy-Author-10.47.28.211

I'll take a look at the link and post back an update.

This may help narrow down the issue.

I am applying this download/deploy script plugin on two different projects. If I hardcode the dependency to use one of the project's artifacts (projectA), it will use $buildDir/distributions/ for itself but resolve correctly when it is executing the fetch for the 2nd project (projectB).

Example:

dependencies {
deployCq group: 'com.scrippsnetworks.wcm', name: 'bulkupdate-osgi', version: '2.2.166', ext: 'zip'
}

----------
StdOut
-----------
:buildSrc:build UP-TO-DATE
Loading configuration for environment 'DEV'.
PATH:C:\Repos\fnr-imp\bulkupdate-osgi\build\distributions\bulkupdate-osgi-2.2.166.zip
Download [1]http://XXXXXX/snilabs/libs-releases/c...
Relying on packaging to define the extension of the main artifact has been deprecated and is scheduled to be removed in Gradle 2.0
Download [2]http://XXXXX/snilabs/libs-releases/co...
PATH:C:\Users\user\.gradle\caches\modules-2\files-2.1\com.scrippsnetworks.wcm\bulkupdate-osgi.2.166c8ca18e9844b7795c6bcdad5463e041e30a7f76\bulkupdate-osgi-2.2.166.zip
:bulkupdate-osgi:fetchDeployArchives UP-TO-DATE
:imp-osgi:fetchDeployArchives
----------------------------------------------------------------------------------------
[1] http://XXXXXX/snilabs/libs-releases/com/scrippsnetworks/wcm/bulkupdate-osgi/2.2.166/bulkupdate-osgi-2.2.166.pom
[2] http://XXXXX/snilabs/libs-releases/com/scrippsnetworks/wcm/bulkupdate-osgi/2.2.166/bulkupdate-osgi-2.2.166.zip

Publishing the artifact with an artifactId other than the project.name is a workaround for this issue.

Thanks for all your help Peter.

I am having the same issue (at least I think so). We are using a dependency to optionally fetch preBuilt GWT builds for non-ui developers, which have the same GAV as the local project (because they are also published by this project in CI). I know this is a bit of a hack, but with gradle 1.x it made lives easier for non-ui devs.

I managed to narrow down the case to following sample project.
I tested this with gradle 1.12, 2.4 and 2.5-rc2
I don't know why, but in our "big" project i only recognized this after upgrade to gradle 2.4, but this testproject also shows the same behaviour with gradle 1.12.

To reproduce:

1. you need a repository at http://host.name/repobase/tmpTestRepo
2. ./gradlew publishMavenJavaPublicationToMavenRepository -Pversion=1.1.1 -PrepoBaseUrl='http://host.name/repobase' -PrepoUser=username -PrepoPass=passwd -> publishes rb:testdependency:1.1.1 (empty jar) into repository (exactly the same version that is referenced in the buildscript
3. ./gradlew testFetchContent -Pversion=1.1.2 -PrepoBaseUrl='http://host.name/repobase' -PrepoUser=username -PrepoPass=passwd -> uses local project which has version 1.1.2 although project explicitely references external module with version 1.1.1

group 'rb'

apply plugin: 'java'
apply plugin: 'maven-publish'

repositories {
    maven { url "$repoBaseUrl/tmpTestRepo" }
    mavenCentral()
}

configurations {
    fetch
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    fetch "rb:testdependency:1.1.1"
}

task testFetchContent << {
    println "content of fetch: ${configurations.fetch.files}"
}

publishing {
    repositories {
        maven {
            url "$repoBaseUrl/tmpTestRepo"
            credentials.username = repoUser
            credentials.password = repoPass
        }
    }
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.