Gradle dependencies in JHipster format "groupId:artifact"

Question

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?

Possibly related: https://stackoverflow.com/questions/41676534/how-are-some-gradle-dependencies-working-with-no-version-supplied — usr-local-ΕΨΗΕΛΩΝ, Sep 26 '19 at 10:18

score 0 · Accepted Answer · answered Sep 26 '19 at 10:23

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

score 0 · Answer 2 · answered Sep 29 '19 at 17:48

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.

Gradle dependencies in JHipster format "groupId:artifact"

Question

2 Answers2

TL;DR

Long answer