Develop Reference

Limit the scope of dependency in gradle

I am using gradle 3.2.1. I have a framework that pulls up dependencies (newer version). But the problem is that my project already has these dependencies (old version) and I don't want to change their version. And the required framework cannot work without a new version. And my question is, can you restrict the built-in dependencies of the framework only for it? and use the same version for my application? is there such a possibility in gradle?
An example of how i exclude the loading of components, but i need to leave them only for this dependency:
compile(group: 'io.javalin', name: 'javalin', version: '4.1.1') {
exclude group: 'org.eclipse.jetty'
exclude group: 'org.eclipse.jetty.websocket'
}

Gradle dependencies in JHipster format "groupId:artifact"

I am posting here to understand how does JHipster work with Gradle dependencies, in particular with regards to the fact that I am unable to copy some of them into a Gradle submodule I have created inside my JH project.
For example, the following doesn't work in a Gradle submodule
compile "junit:junit"
Error is
Could not resolve: junit:junit
However, the classic one copied from mvnrepository works great
compile group: 'junit', name: 'junit', version: '4.12'
Some additional information: I am creating a submodule that contains a set of classes related to testing, mainly a large load of custom Hamcrest matchers copied from another project from the Ant world. The original project had a lot of spaghetti code mess, so now I am refactoring into an isolated Gradle module. The testlib module shall depend on the testing frameworks and contain everything required for writing good tests. It can be compared to spring-test project you would use to write your own Spring-based tests.
At the moment, the gradle file looks like
plugins {
id "java"
}
configurations {
providedRuntime
implementation.exclude module: "spring-boot-starter-tomcat"
}
repositories {
mavenLocal()
mavenCentral()
jcenter()
}
group 'org.example' //different from com.acme of super-project
version '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
dependencies {
compile group: 'org.assertj', name: 'assertj-core', version: '3.13.2'
compile group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: '5.5.2'
compile group: 'org.hamcrest', name: 'hamcrest', version: '2.1'
compile group: 'org.mockito', name: 'mockito-core', version: '3.0.0'
compile group: 'org.springframework.boot', name: 'spring-boot', version: spring_boot_version
compile "junit:junit" //Fails
}
Question
So the question is in two parts:
why does the scope "orgId:name" syntax work in the JHipster-generated module but not in submodules? Is it part of standard Gradle syntax?
why is that not working in a sub-module? Does JHipster apply a custom plugin to apply the correct version number that is clearly missing? How I do the same in a sub-module that is supposed to contain only Java library code?

With regards to JHipster, a little of more investigation helped. According to this answer, there is a trick in Gradle called Bill Of Materials project, so...
TL;DR
Add the following to the sub-project
// import JHipster dependencies BOM
implementation platform("io.github.jhipster:jhipster-dependencies:${jhipster_dependencies_version}")
So that the whole block looks like
dependencies {
// import JHipster dependencies BOM
implementation platform("io.github.jhipster:jhipster-dependencies:${jhipster_dependencies_version}")
compile "org.assertj:assertj-core"
compile "org.junit.jupiter:junit-jupiter-api"
compile "org.hamcrest:hamcrest"
compile "org.mockito:mockito-core"
compile "org.springframework.boot:spring-boot"
compile "junit:junit"
}
Long answer
Maybe in the future when I will understand Gradle more. Or just edit this answer 😁 to contribute

The bom defines the versions (besides other things) of 3rd party dependencies to be used so you can omit the explicit version. If you do not use the bom you can also write compile "junit:junit:4.12" but keep in mind jhipster uses already junit5 for all tests by default.
Regarding the import of the bom you can do it like you proposed or try to apply that dependency to all gradle subprojects in your main gradle file.

Same interface in 2 different dependency issue

I have conflict problem with dependencies.
My project has two dependencies like this:
dependencies {
provided group: 'javax.servlet', name: 'javax.servlet-api', version: '3.1.0'
compile files('path/to/ABC.jar')
}
ABC.jar has its own dependency to javax.servlet:servlet-api:
dependencies {
provided group: 'javax.servlet', name: 'servlet-api', version: '2.5'
}
Here is the problem I am dealing with; I need to use ServletContext interface which is provided by both servlet-api libraries and the compiler uses wrong one.
Gradle auto-resolves version conflicts as described here.
But in my case it doesn't help, because it only works when a dependency has two different versions. In this case; although it's a newer version issue, the name has changed from javax.servlet:servlet-api to javax.servlet:javax.servlet-api. So gradle doesn't auto-resolve this conflict, because it doesn't seem to be a version issue.
The thing I tried was using excluding transitive dependency as described here.
compile files('path/to/ABC.jar') {
exclude group: 'javax.servlet'
}
But it didn't work, it seems exclude doesn't work on local 'jar' files.
Now, I don't know what else to do.
How can I exclude a dependency of a dependency which is added as a local file?
(If the first question doesn't have any answer yet) How can I say to the compiler to use the correct ServletContext interface?

compile files('path/to/ABC.jar') is a file dependency, a file dependency does not have any dependency information, so it does not introduce transitive dependencies. If this ABC.jar is a "fat" jar that has the dependency-classes included in the JAR, it is not suited for usage in something like Gradle, Maven or Ant/Ivy that is supposed to handle the dependencies. You would have to use a proper "thin" version of the dependency with the dependencies properly declared, or you need to "repackage" that JAR in your build script to exclude the dependency classes you don't want to pull in. No dependency management can do this for you.
You can execute gradlew dependencyInsight --configuration runtime --dependency javax.servlet:servlet-api or gradlew dependencies --configuration runtime to find out where the dependency really comes from.
Actually your example should not even compile if I see it correctly, because it should most probably be
compile files('path/to/ABC.jar'), {
exclude group: 'javax.servlet'
}
or
compile(files('path/to/ABC.jar')) {
exclude group: 'javax.servlet'
}
But as I said, with a local file dependency there are no transitive dependencies, so an exclude does not make sense at all anyway.
To make the Gradle version conflict magic work, you can simply tell Gradle that those libraries are actually the same library just with different coordinates by using a module replacement like
dependencies {
modules {
module('javax.servlet:servlet-api') {
replacedBy 'javax.servlet:javax.servlet-api'
}
}
}
Then Gradle sees them as the same library and can do its version conflict resolution magic. Whether the library that needs the old version still works with the new version is a different topic that you have to check and / or try yourself. This like always depends on whether the new version is backwards compatible to the old version.

I have no way to test this now, but I believe your syntax is wrong. I have some examples here that look different, in your case it would be:
compile(files('path/to/ABC.jar')) {
exclude group: 'javax.servlet'
}
As I say, I cannot test it now, check if it helps and give a comment.

Multiproject build: dependency to tests jar

I'm restructuring/refactoring build process for a big(ish) project. Currently it contains over a dozen separate modules built with standalone build scripts each. I want to integrate them all into a single multiproject build in Gradle.
After I integrated all sources into a single tree, fixed build.gradles, I came upon the following problem. Dependencies for many modules contain something like:
dependencies {
compile group: 'com.company', name: 'Module', version: '1.2.3'
// ...
testCompile group: 'com.company', name: 'Module', version: '1.2.3', classifier: 'tests'
}
I want the build to use jars from the subproject, not from a repository. I replaced compile ... with compile project(':Module') and it works fine. However, I cannot find the way to pass 'tests' specifier to the testCompile project... dependency.
Is there a way to pick up the tests jar as a dependency to testCompile?

In the producing project you will need to declare the "Test" JAR as outgoing artifact.
configurations {
testUtils
}
task testUtilsJar(type: Jar) {
...
}
artifacts {
testUtils testUtilsJar
}
In the consuming project you depend on it as such:
dependencies {
testCompile project(path: ':Module', configuration: 'testUtils')
}

Gradle subproject jar and add to Eclipse referenced libraries

I have a repo at http://www.github.com/kourbou/HyperQuest.
I have a git submodule to a project called SpongeAPI. I would like to add the compiled jar of the subproject to the Eclipse project automatically but I have failed at doing so. I have added this to my gradle.build :
dependencies
{
jar project('SpongeAPI')
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
But the build fails and this happens:
A problem occurred evaluating root project 'HyperQuest'.
> Could not find method jar() for arguments [project ':SpongeAPI'] on root project 'HyperQuest'.
Could someone give me an example or write a gist of a build.gradle that works? Thanks.

Either set up multi-project build or publish the output of SpongeAPI into some repository and consume it from that place.
Multi-project build is described in http://www.gradle.org/docs/current/userguide/tutorial_java_projects.html#sec:examples - you will add settings.gradle that will include SpongeAPI and then the dependency is like compile project(':SpongeAPI').
The publish approach means that you will upload the artifact from SpongeAPI build into a repository and your build will add this repository (like you add mavenCentral() or jcenter()) and refer to your artifact using common notation. Again there is a documentation to help you with that - http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html#N10669

I know you posted this early on in SpongeAPI's development, but I'll add this here for future readers.
By including SpongeAPI as a git-submodule, you are potentially tying your plugin to a specific, in development version of the API.
Instead, we provide a maven repository that you should use at https://repo.spongepowered.org/maven/
When using a version of SpongeAPI you MUST stick to released API versions, and not snapshots.
Otherwise your plugin has the potential to break on dev releases of the API.
You can read up to date information on how to set up a Sponge Plugin project here: https://docs.spongepowered.org/stable/en/plugin/project/index.html