I know there are four basic configurations, compile, runtime, testCompile, and testRuntime. If I put in a dependency like this:
runtime group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.3'
This means this dependency is available under runtime and compile, correct? But what about testCompile and testRuntime? Is it available for these configurations as well? If I add my own configuration, do I have to specify where it exists in the hierarchy? What happens if I don't? The documentation didn't really make this clear.
The definition for those 4 configuration are as follow for the java plugin :
compile
The dependencies required to compile the production source of the project.
runtime
The dependencies required by the production classes at runtime. By default, also includes the compile time dependencies.
testCompile
The dependencies required to compile the test source of the project. By default, also includes the compiled production classes and the compile time dependencies.
testRuntime
The dependencies required to run the tests. By default, also includes the compile, runtime and test compile dependencies.
you can also check https://docs.gradle.org/current/userguide/java_plugin.html#tab:configurations, it has pretty graph and table:
When you declare a new configuration you can define what other configuration it extends, for example Gradle In Action takes the example with Geb, you would define new configuration as
configurations {
functTestCompile.extendsFrom testCompile
functTestRuntime.extendsFrom testRuntime
}
If you dont, you assume those configuration do not need to benefit from another one and its standalone, you will need to define all dependencies this configuration requires.
Related
We have been using gradle spring boot plugin version 1.5.14 and gradle 4.10.3 for our builds. After an upgrade of gradle to 6.2.2, we've also changed dependency-definition from compile group to implementation group i.e.:
compile group: 'org.springframework.boot', name: 'spring-boot-starter-integration'
to
implementation group: 'org.springframework.boot', name: 'spring-boot-starter-integration'.
The fat jar created via gradle assemble does to my surprise not contain the required libs under BOOT-INF/lib anymore? If I replace "implementation" with "compile" it works again as expected.
Is there something which needs to be configured so that spring-boot-plugin adds them? Or do I need to upgrade the project to spring boot 2 beforehand?
Implementation will bring in the dependency only for that module it is declared in.
Compile will allow a module that depends on the module to use the dependency as well.
Say you have Module A depending on Module B.
Module A and B both need the dependency:
com.font:font1:1.1.1
If B uses:
implementation 'com.font:font1:1.1.1'
A will not see font1, and will need to bring it into its own build.gradle file as well.
compile 'com.font:font1:1.1.1'
will make it available to the entire classpath (which should be avoided anyway, and the new equivalent is for libraries which uses 'api' instead of 'compile').
Without seeing your project directory, I'm assuming that some dependency is not being pulled into a place where it used to be grabbed from a lower dependency in the hierarchy. You should be able to find the missing dependencies easily by changing compile to implementation one at a time, unless you have a huge multi-module project.
I have a project "lib" with declares dependency on third party library (lets say, redis).
dependencies{
implementation group: 'redis.clients', name: 'jedis', version: '2.9.0'
}
I have another project, "application", which is declares dependency on "lib" project in very similar way.
The problem: unless I adding redis dependency to the "application" project as well, it fails at runtime due to missing redis dependency (despite that it itself doesn't make any direct use of redis).
I want to declare "redis" dependency inside "lib" project in such way, so "lib" will be already "bundled" with "redis" inside, so everyone using "lib" will have to declare only "lib" dependency.
How to do that?
Assuming you apply the java or java-library plugins, you should not have to do anything.
A dependency added to the implementation scope in Gradle is visible to consumers of that project for their runtime classpath. It is however not visible to the compile classpath.
In order to understand better what's happening, you can check the different classpath by running ./gradlew <project>:dependencies --configuration runtimeClasspath on both projects and see what is the output, of course replacing <project> with the project name or leaving empty for the root project.
In a gradle build script I've the following piece of code:
dependencies {
runtime group: 'org.springframework', name: 'spring-core', version: '4.1.1'
}
and it works fine, but if I change it to
dependencies {
compile group: 'org.springframework', name: 'spring-core', version: '4.1.1'
}
an exception will be thrown during gradle build
Could not resolve all dependencies for configuration ':compile'.
> Could not find org.springframework:spring-core:4.1.1.
Searched in the following locations:
https://repo1.maven.org/maven2/org/springframework/spring-core/4.1.1/sprin
g-core-4.1.1.pom
https://repo1.maven.org/maven2/org/springframework/spring-core/4.1.1/sprin
g-core-4.1.1.jar
I thought the artifact searching for in the same place for both compile and runtime. What are differences between them?
Gradle resolves compile dependencies before it performs compilation, expecting that the source code will reference the artifact directly. However, it does not resolve runtime dependencies until later in the build process. (See #Dónal 's answer for usage guidelines in choosing between compile and runtime)
Thus, it is most likely that the difference between the two cases is that your build task required compilation, but not runtime prep. With your original configuration, any task requiring runtime prep would have failed with the same error.
To fix the failure in this specific case, I recommend changing your version value from 4.1.1 (which is not in the Maven repository you reference) to 4.1.1.RELEASE (which is).
I've got a project that I want to use providedCompile with to avoid pulling it's libs. However, that prevents me from pulling in another project's libs that I do need. The docs say: If you don't want this transitive behavior, simply declare your provided dependencies, but it doesn't give an example of how to do this.
Here's basically what my dependencies look like:
dependencies {
compile(project(':common'))
providedCompile(project(':projA')) // <-- also depends on :common
}
My war file correctly excludes all of transitive libs from projA, but I need to trump that for the common.jar and I can't figure out how to make that happen. But the docs seem to indicate it's possible...
Edit: Here's a hacky configuration that seems to work. The combination of lines for "projA" gives me projA.jar as a dependency, but not its children. And since "common" is a compile dependency, but "projA" is only considered provided at runtime, I still get the common.jar due to the compile time dependency. I'm not sure it's supposed to work this way, but it generates the war I need.
dependencies {
compile(project(':projA')) { transitive = false }
providedRuntime(project(':projA')) { transitive = false }
compile(project(':common'))
}
If you don't want this transitive behavior, simply declare your provided dependencies
This means that if you don't want all dependencies of projA to be declared provided you need to list them as provided one by one.
From the Gradle 1.8 Userguide '26.4. Dependency management'
The War plugin adds two dependency configurations: providedCompile and
providedRuntime. Those configurations have the same scope as the
respective compile and runtime configurations, except that they are
not added to the WAR archive. It is important to note that those
provided configurations work transitively.
Let's say you add commons-httpclient:commons-httpclient:3.0 to any of
the provided configurations. This dependency has a dependency on
commons-codec. This means neither httpclient nor commons-codec is
added to your WAR, even if commons-codec were an explicit dependency
of your compile configuration. If you don't want this transitive
behavior, simply declare your provided dependencies like
commons-httpclient:commons-httpclient:3.0#jar.
There is another better solution that seems to be working. With transitive=false you exclude all the transitive dependencies that are then missing during compilation time and you have to declare all of them manually (again as provided) which is pain if they also include your desired library.
So for the providedCompile statement exclude not all transitive dependencies but only the one you want to include in war by separate compile statement.
Real example where I need the commons-codec included in the war file but that one is placed also in the keycloak-services and keycloak-model-jpa:
providedCompile ("org.keycloak:keycloak-model-jpa:6.0.1") {
exclude group: 'commons-codec', module: 'commons-codec'
}
providedCompile ("org.keycloak:keycloak-services:6.0.1") {
exclude group: 'commons-codec', module: 'commons-codec'
}
providedCompile "org.keycloak:keycloak-core:6.0.1"
providedCompile "org.keycloak:keycloak-server-spi:6.0.1"
providedCompile "org.keycloak:keycloak-server-spi-private:6.0.1"
compile "commons-codec:commons-codec:1.10"
I'm trying to use spring-test-mvc for testing a controller in my little application. Since I use gradle as build tool I added the dependency to it like this:
testCompile 'org.springframework:spring-test-mvc:1.0.0.M1'
It succeeds to retrieve spring-test-mvc, and compile the tests. But executing the tests fails, because it doesn't seem to include transient dependencies like mvc test.
Among others it complains about not finding
org.springframework.mock.web.MockHttpServletRequest
Which is part of the spring-test.jar, which is included as a dependency in spring-test-mvc s pom.xml https://github.com/SpringSource/spring-test-mvc/blob/master/pom.xml
I can fix that problem by including the dependency explicitely in the build file:
testCompile 'org.springframework:spring-test:3.1.1.RELEASE'
But it just gets replaced by the next problem. I tried to explicitly ask for transient dependencies:
testCompile ('org.springframework:spring-test-mvc:1.0.0.M1') {
transitive = true
}
But that doesn't seedm to change anything.
So the question is: How do I get gradle to include transitive dependencies in the classpath.
Note: Transitive dependencies seem to work fine outside of tests.
It's a problem with the POM. http://repo.springsource.org/libs-milestone/org/springframework/spring-test-mvc/1.0.0.M1/spring-test-mvc-1.0.0.M1.pom does not declare any dependencies.