Skip to content
This repository has been archived by the owner on Apr 19, 2018. It is now read-only.

Downloading target 22 doesn't work #70

Open
jakubkrolewski opened this issue Mar 23, 2015 · 9 comments
Open

Downloading target 22 doesn't work #70

jakubkrolewski opened this issue Mar 23, 2015 · 9 comments

Comments

@jakubkrolewski
Copy link

$ ./gradlew assembleDebug
Picked up JAVA_TOOL_OPTIONS: -Xmx2048m -XX:MaxPermSize=1024m -Xms512m -Dfile.encoding=UTF-8
Gradle 2.2.1
Compilation API android-22 missing. Downloading...

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\(...)\build.gradle' line: 122

* What went wrong:
A problem occurred evaluating project ':root'.
> Failed to apply plugin [id 'android-unit-test']
   > failed to find target android-22 : C:\opt\android-sdk-windows

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

What's interesting, the SDK was actually downloaded correctly, so after running the build again nothing was missing any more and the build succeed.

@plastiv
Copy link

plastiv commented Mar 23, 2015

That's a known issue already. (#10, #47)

This is due to the way gradle resolves dependency scope before any task is ever run and don't update it later.

Use next workaround:

./gradlew clean --continue
./gradlew clean assemble

@rohans310
Copy link

Any idea how I could do this on Jenkins? @jakubkrolewski like you said, looks like it is downloading the dependencies but failing for some reason. Everytime i build it tries to download the dependencies and then fails with the error - failed to find target android-22 : /usr/local/android-sdk

@EKami
Copy link

EKami commented Apr 17, 2015

Same error here with circleci

@ScottPierce
Copy link

@plastiv That workaround doesn't seem to work, and it still fails a Jenkins build.

@carlesferrer
Copy link

+1

@ncalexan
Copy link

I witnessed this today. There are 3 identical tickets so this appears to be an oft-reported, high priority issue. @plastiv: you seem to understand this from the Gradle perspective. Can you give as much detail about the cause as you can? I will reach out to the Gradle team and see if we can build a work-around.

@plastiv
Copy link

plastiv commented Oct 26, 2015

@ncalexan My best guess is that due to code

  def findDependenciesWithGroup(String group) {
    def deps = []
    for (Configuration configuration : project.configurations) {
      for (Dependency dependency : configuration.dependencies) {
        if (group.equals(dependency.group)) {
          deps.add dependency
        }
      }
    }
    return deps
  }

from here https://github.com/JakeWharton/sdk-manager-plugin/blob/master/src/main/groovy/com/jakewharton/sdkmanager/internal/PackageResolver.groovy#L271-L274
where sdk-manager-plugin scans project dependencies to find support libraries it also triggers gradle to resolve configuration.
Because of support lib isn't downloaded yet at that point and because of gradle caches resolved configuration then project sees unresolved dependencies (even though they are downloaded).

Unfortunately, I don't see an api to skip cache and force to resolve dependencies again after downloading. https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.Configuration.html#org.gradle.api.artifacts.Configuration:resolvedConfiguration
If you know how to trigger it, maybe a fix for this issue.

@Manabu-GT
Copy link

I was having the same issue.
The workaround I did was to add

./gradlew -refresh-dependencies

before

./gradlew clean assembleDebug -PdisablePreDex

Depending on your set up, doing "-refresh-dependencies" every time takes long time and might not be an acceptable workaround.

"The --refresh-dependencies option tells Gradle to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded." quoted from Gradle manual.

@joebowbeer
Copy link

I suspect that ./gradlew --refresh-dependencies works in the same way that adding any extra ./gradlew invocation works. In other words, I doubt it works any better than:

./gradlew clean || true
./gradlew assembleDebug

or

./gradlew dependencies || true
./gradlew clean assembleDebug

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants