I’m trying to build an Android project using Cordova, but I’m getting the following error:
Could not resolve all artifacts for configuration ':CordovaLib:classpath'. Could not find com.jfrog.bintray.gradle:gradle-bintray-plugin:1.7.3.
I’ve checked the download locations mentioned in the error and it seems that the plugin is not available. I’ve also tried --stacktrace, but I’m not getting any more relevant information. Does anyone know how to resolve this issue or have any suggestions on how to proceed?
I have managed to resolve the above issue, however, I am now facing a new error related to the Bintray library, which requires the http-builder.0.7.2 dependency. I tried applying the same solution as before, adding the https://nexus.web.cern.ch/nexus/content/repositories/public/ repository in the platforms/android/app/build.gradle file. I also added the following line in the dependencies: classpath 'org.codehaus.groovy.modules.http-builder:http-builder:0.7.2'.
Additionally, I tried including the repository in the platforms/android/build.gradle file, but doing so, it no longer recognized the Bintray dependency. Now I am not sure how to make both dependencies work properly. I would appreciate any guidance you could provide.
NOTA!! La solucion para lo de bintray fue agregar los siguientes repositorios en el platforms/android/build.gradle:
maven { url 'https://plugins.gradle.org/m2/' } can be replaced by gradlePluginPortal().
I strongly recommend not to use JitPack if you can anyhow avoid using it, and if you really need it, at least use a content repository filter to define what exactly to take from there. It is broken-by-design as normal repository, unreliable, buggy, and slow.
You should not use a buildscript { ... } block to add plugins to the classpath, but use the plugins { ... } block instead to apply plugins, or to add them to the classpath.
You should not depend on gradlePluginPortal() in your normal repositories unless you develop an actual Gradle plugin where you need other plugins as production dependencies
Using allprojects { ... } or any other means of cross-project configuration is highly discouraged. It immediately introduces project coupling and works-against or disables some more sophisticated Gradle features and optimizations. Instead use convention plugins to centralize build logic, for example in buildSrc or an included build, for example implemented as precompiled script plugin.
More a personal recommendation, I strongly suggest switching to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpful error messages if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio.
buildscript {
repositories {
google()
mavenCentral()
maven { url 'https://plugins.gradle.org/m2/' }
maven { url 'https://groovy.jfrog.io/artifactory/libs-release/' }
jcenter()
}
dependencies {
// The gradle plugin and the maven plugin have to be updated after each version of Android
// studio comes out
classpath 'com.android.tools.build:gradle:3.3.0'
classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'
classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.7.3'
}
}
allprojects {
repositories {
google()
mavenCentral()
maven { url 'https://plugins.gradle.org/m2/' }
maven { url 'https://groovy.jfrog.io/artifactory/libs-release/' }
jcenter()
}
}
https://plugins.gradle.org/m2/ is needed for com.jfrog.bintray.gradle https://groovy.jfrog.io/artifactory/libs-release/ is needed for org.codehaus.groovy.modules.http-builder
Is that a try to answer something or do you have some problem?
If the latter, is it related to this thread?
Your snippets are also full of discouraged bad practices or time-waste.
For example you can use gradlePluginPortal() instead of manual URL.
Using jcenter() is pointless, by now it is just a redirect to mavenCentral() and thus wasting time for any non-found lib that is searched in mavenCentral() twice.
Using buildscript { ... } is not a good idea for plugins, the recommended way is to define plugin repositories in your settings script and using the plugins { ... } block to apply the plugins or bring them onto the classpath. allproject { ... } or any other means of doing cross-project configuration or even cross-project model information gathering is highly discouraged as it immediately introduces project coupling which works against more sophisticated Gradle features and optimizations.
Sorry for the lack of context, I was actually trying to get a legacy Ionic project to build again, which is using Cordova-Android v8.1.0 from back in 2020-ish
and the error is in Gradle file of cordova-android during the build process
I was faced with the same errors that the OP, Isaac faced (I believe he is also using cordova-android)
Additionally, your input about the http-builder dependency helped me a lot in getting it fixed, I did indeed face error with http-builder.
The “bad code” is from the developers of cordova-android, I merely just added the maven repositories and to reduce unnecessary changes to getting it to work, hence remained the reference to jCenter().
Any one who wants to fix their copy of old cordova-android can simply remove it as well
cordova-android developers are no longer making any changes to this version, I really appreciate your inputs such as the redundant allprojects {...}, and will take notice of them in the future!
I really appreciate your inputs such as the redundant allprojects {...}
Redundant is the wrong word. allprojects { ... } does do something unless you only have one project anyway, then it is indeed just redundant.
In any other case it is highly discouraged bad practice and should be replaced by something else, in that case dependencyResolutionManagement { repositories { ... } } in the settings script, in other cases by convention plugins.
