I am trying to import org.scalatra:scalatra-atmosphere:2.2.0-RC3 into a Scala 2.10 project. The issue is that this package depends on the two non-Scala-versioned packages com.typesafe.akka:akka-actor:2.0.4 and com.typesafe.akka:akka-testkit:2.0.4 (org.scala-lang:scala-library:2.9.2 and org.scalatra:scalatra-json:2.2.0-RC3 should work fine, as they will go to newest). As far as I can tell, the Akka dependencies do not exist on Maven Central, so we have broken packages.
I would like to override org.scalatra:scalatra-atmosphere:2.2.0-RC3's dependencies by hand by replacing the non-Scala-versioned packages with Scala-versioned packages that actually exist:
configurations.all {
resolutionStrategy {
eachDependency { details ->
if (details.requested.group == 'com.typesafe.akka') {
details.requested.name += "_$scalaVersion"
details.useVersion '2.1.0'
}
}
}
}
Unfortunately, this technique appears to be explicitly disallowed as of Gradle 1.4:
What went wrong:
Could not resolve all dependencies for configuration ':compile'.
> new ModuleRevisionId MUST have the same ModuleId as original one. original = com.typesafe.akka#akka-actor new = com.typesafe.akka#akka-actor_2.10
Is there a legitimate way to work around this issue?
Only version changes are supported in 1.4, 1.5 is due to contain support for changing the other attributes of a dependency.
I think your options are variations on excluding the specific dependency and adding it back in by hand. Examples can be found in the docs
dependencies {
compile("org.scalatra:scalatra-atmosphere:2.2.0-RC3) {
exclude group: 'com.typesafe.akka', module: 'akka-actor'
exclude group: 'com.typesafe.akka', module: 'akka-testkit'
}
// assuming you have this available in a repository your build is configured to resolve against
compile 'com.typesafe.akka:akka-actor:2.0.4-MY.LOCAL.VERSION'
}
Related
I am trying to use OSGI to allow me to use two different versions of a transitive dependency. The plan is that one version (the newer version) will be hidden away inside an OSGI bundle, the other will be on the runtime classpath as normal.
I have built the bundle jar using Gradle (with the Groovy DSL), but the problem is its associated runtime dependencies are wrong - it brings along the newer version, which is supposed to be hidden inside the bundle. This is still true when I do, in the build.gradle file:
compileOnly deps.diffx
runtimeOnly(deps.diffx) {
exclude group: 'com.propensive', module: 'magnolia_' + versions.scala_v
}
If I examine the dependencies with the Gradle dependencies task, it shows that magnolia is excluded from the runtimeOnly configuration, as expected - but is not excluded from the runtimeClasspath configuration.
If I then use ./gradlew dependencyInsight --dependency magnolia_2.12 --configuration runtime to try to find out where this dependency is coming from, it tells me that the newer version is coming from runtimeClasspath depending on diffx, and this is selected via conflict resolution. Well thanks - I already knew that. The question is, why is my exclusion not being applied to the derived configuration?
Basically I want to do the opposite of this question.
I also tried constraint versions, but they exhibited the same problem:
compileOnly deps.diffx
runtimeOnly(deps.diffx) {
constraints {
implementation('com.propensive:magnolia_' + versions.scala_v + ':0.10.0') {
because 'this version is required by our other dependencies'
}
}
}
From the Gradle documentation:
On the upside, Gradle’s exclude handling is, in contrast to Maven, taking the whole dependency graph into account. So if there are multiple dependencies on a library, excludes are only exercised if all dependencies agree on them. For example, if we add opencsv as another dependency to our project above, which also depends on commons-beanutils, commons-collection is no longer excluded as opencsv itself does not exclude it.
So instead, we can use a dependency resolve rule:
def magnoliaVersion = '0.10.0'
configurations.runtimeClasspath {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
if (details.requested.group == 'com.propensive' && details.requested.name.startsWith("magnolia_") && details.requested.version != magnoliaVersion) {
details.useVersion magnoliaVersion
details.because 'this version is required by our other dependencies'
}
}
}
and then change the dependency back to a simple, single implementation one:
implementation deps.diffx
Unfortunately, as the documentation notes, this resolve rule isn't published, so it has to be applied again in any dependent Gradle modules.
Can someone explain to me how depedencies listed in the "buildscript" in the build.gradle file are different than regular dependencies listed in the dependencies block { } ? and why they have to be listed with the syntax "implementation"? I've googled this and responses say the dependencies in the buildscript and used to "build the project" but I don't understand this? can anyone give a more clear picture and answer?
buildscript:
buildscript
{
repositories
{
maven {
url 'myMavenFeed'
credentials {
username "myUsername"
password myPassword
}
}
mavenCentral()
jcenter()
}
dependencies
{
classpath "com.microsoft.azure.sdk.iot:iot-device-client:1.14.1"
}
}
Dependencies block:
dependencies
{
compile group: 'com.microsoft.azure.sdk.iot', name: 'iot-device-client', version: '1.16.0'
}
Can someone explain to me how depedencies listed in the "buildscript" in the build.gradle file are different than regular dependencies listed in the dependencies block { } ?
Dependencies defined in the buildscript { } block are dependencies to use to build your project. These dependencies are available to use in your Gradle build file (build.gradle or build.gradle.kts)
Dependencies defined in the dependencies { } are for your application code.
So for your samples in your questions, does it make sense for Gradle (the build system) to have iot-device-client on its classpath? Why does a build system need iot-device-client on its classpath to build your project? It doesn't make sense therefore it should be removed.
Now let's say you are developing an application the requires some functionality or class from iot-device-client. You need a way to add this library to your application's code/classpath. You when then declare it as a dependency as you have done above:
dependencies {
implementation("com.microsoft.azure.sdk.iot:iot-device-client:1.16.0")
}
References:
External dependencies for the build script
Declaring depenedncies
and why they have to be listed with the syntax "implementation"?
implementation is known as a configuration: A Configuration represents a group of artifacts and their dependencies
There are many more configurations depending on the plugins you apply to your project. For example, if you apply the Java plugin:
plugins {
id("java")
}
The following configurations are available to use:
implementation
compileOnly
compileClasspath
...and many more
Each one has their own meaning/usage and I strongly suggest reading about them here.
I have a gradle Project where I have a dependency on "hudson-core 3.3.3"
compile group: 'org.eclipse.hudson', name: 'hudson-core', version: '3.3.3'
This works without a problem when using Gradle 5.6.2
When I upgrade to Gradle 6.0.1 I receive the following error:
Could not resolve org.eclipse.hudson:hudson-remoting:3.0.3.
Required by:
project : > org.eclipse.hudson:hudson-core:3.3.3
project : > org.eclipse.hudson:hudson-core:3.3.3 > org.eclipse.hudson:hudson-cli:3.3.3
> Could not resolve org.eclipse.hudson:hudson-remoting:3.0.3.
> inconsistent module metadata found. Descriptor: org.eclipse.hudson:hudson-remoting:3.0.4-SNAPSHOT Errors: bad version: expected='3.0.3' found='3.0.4-SNAPSHOT'
The Repository is always the same:
repositories {
mavenCentral()
maven {
url 'http://repo.jenkins-ci.org/public/'
}
}
Any Ideas why this error happens?
As said by #ToYonos, the problem is in the dependency itself.
Not perfect solutions, but 2 workarounds can be done as explained in Gradle's documentation (v6.7.1):
Exclude that transitive dependency, for example in the current Gradle versions using implementation instead of compile:
implementation('org.eclipse.hudson:hudson-core:3.3.3') {
exclude group: 'org.eclipse.hudson'
exclude module: 'hudson-remoting'
}
Override that transitive dependency version:
implementation('org.eclipse.hudson:hudson-remoting') {
version {
strictly '3.0.2' // As 3.0.3 is having the issue
}
}
In the pom.xml file of hudson-remoting 3.0.3, the version is <version>3.0.4-SNAPSHOT</version>
The issue is quite clear.
I tried with an old Gradle 4.4.1 and I am having the exact same issue. Likewise with Gradle 5.1.1 and your version, 5.6.2
I'm quite sure that if you clean your artefact cache for Gradle 5.6.2, it won't work anymore.
The error is on the repository side.
Another option is to define a repository that will download only a jar:
repositories {
mavenCentral() {
name = "Download only jar repo"
metadataSources { artifact() }
content {
// Use this repository only for org.eclipse.hudson:hudson-remoting
includeVersion("org.eclipse.hudson", "hudson-remoting", "3.0.3")
}
}
mavenCentral()
}
Also since pom is not downloaded you would have to add hudson-remoting dependencies by hand to build.gradle. But luckily for this particular case hudson-core already contains the only dependency commons-codec:commons-codec:1.4 that hudson-remoting needs, so this is not needed.
Note: the order of repositories is important, although in that case it will work either way. If you don't want to care about the order when using repositories with filter check exclusive content filtering.
I am using the Spring Boot Gradle plugin and its dependency management to manage some of my own dependencies across project so I do not need to add an explicit version in the build.gradle.
dependencyManagement {
dependencies {
dependency "foo.bar:my-own-library:12.1"
}
}
The problem is that I need another version "11.9" beside the version "12.1" and that I wanted the plugin to pick the correct version based on a variable.
So I added a resolutioStrategy and some variables in ext:
dependencyManagement {
dependencies {
dependency "foo.bar:our-own-library:12.1"
}
resolutionStrategy {
eachDependency { details ->
//find available version based on src_compat
//set the new version to use via
details.useVersion(newVersion)
// details.target.version yields updated version
}
}
}
ext {
src_compat = 11
extra_versions = ["foo.bar:my-own-library" : ["11.9"]]
}
The target version is set correctly every time but than the old version (12.1) is used for every configuration.
The configurations have no other custom resolutionstrategy.
My assumption was the resolutionStrategy of the plugin is able to override every version when the dependency management of the plugin is used.
Is the resolutionStrategy able to override all versions or do I have to move it the 'normal' gradle configurations?
There's some information about this in the dependency management plugin's documentation.
The dependency management resolution strategy only applies to the plugin's internal configurations, such as those that it uses to resolve the Maven boms that you have imported. As you suspected, if you want the resolution strategy to apply to the resolution of your project's dependencies, you should move it to the normal Gradle configurations.
I have a library, which I call core, which is a dependency of another project, called Museum. In core's build.gradle, I am using gson-fire, which is specified as a dependency in the following manner:
repositories {
maven { url 'https://raw.github.com/julman99/mvn-repo/master'}
}
...
dependencies {
compile 'com.github.julman99:gson-fire:0.11.0'
}
This works fine - core is compiled. When I go to use it in my Museum project, though, I get the following:
A problem occurred configuring project ':Museum'.
> Could not resolve all dependencies for configuration ':Museum:_debugCompile'.
> Could not find com.github.julman99:gson-fire:0.11.0.
Searched in the following locations:
file:/Users/jwir3/.m2/repository/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.pom
file:/Users/jwir3/.m2/repository/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.jar
http://download.crashlytics.com/maven/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.pom
http://download.crashlytics.com/maven/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.jar
https://repo1.maven.org/maven2/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.pom
https://repo1.maven.org/maven2/com/github/julman99/gson-fire/0.11.0/gson-fire-0.11.0.jar
Required by:
museum:Museum:unspecified > com.jwir3.core:core:1.4.0-SNAPSHOT
The build.gradle of Museum looks like the following:
dependencies {
compile ('com.thisclicks.core:core:' + project.CORE_LIB_VERSION+ '+#aar') {
transitive = true
}
}
Presumably, this is because the core library is specified as transient = true in the build.gradle of Museum, but it doesn't have the correct location to search for the Maven repository of gson-fire. Is there a way to make these search locations transient as well as the dependencies themselves?
Not automatically, no. Transitive dependencies do not bring in repository information, only the artifacts themselves. If you want this to work you'll have to add the repositories { } block from the core project to the Museum project.
Additionally, adding transitive = true is unnecessary in this case. This is the default anyway, and as explained above, is unrelated to this particular issue.