Зависимости Gradle в формате JHipster "groupId: artifact" - PullRequest
0 голосов
/ 26 сентября 2019

Я публикую здесь, чтобы понять, как работает JHipster с зависимостями Gradle, в частности, в связи с тем, что я не могу скопировать некоторые из них в подмодуль Gradle Iсоздали в моем проекте JH.

Например, следующее не работает в подмодуле Gradle

compile "junit:junit"

Ошибка

Could not resolve: junit:junit

Однако классическийодин скопирован из mvnrepository отлично работает

compile group: 'junit', name: 'junit', version: '4.12'

Некоторая дополнительная информация: я создаю подмодуль, который содержит набор классов, связанных с тестированием, в основном это большая загрузка пользовательских совпадений Hamcrest, скопированных изеще один проект из мира муравьев.В первоначальном проекте было много беспорядочных спагетти-кодов, так что теперь я реорганизуюсь в изолированный модуль Gradle.Модуль testlib должен зависеть от инфраструктуры тестирования и содержать все необходимое для написания хороших тестов.Его можно сравнить с проектом spring-test, который вы бы использовали для написания собственных тестов на основе Spring.

На данный момент файл Gradle выглядит как

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
}

Вопрос

Итак, вопрос состоит из двух частей:

  1. Почему синтаксис scope "orgId:name" работает в сгенерированном JHipster модуле, а не в подмодулях?Это часть стандартного синтаксиса Gradle?
  2. , почему это не работает в субмодуле?Применяет ли JHipster собственный плагин для применения правильного номера версии, который явно отсутствует?Как мне сделать то же самое в подмодуле, который должен содержать только код библиотеки Java?

Ответы [ 2 ]

0 голосов
/ 29 сентября 2019

Bom определяет версии (помимо прочего) сторонних зависимостей, которые будут использоваться, так что вы можете опустить явную версию.Если вы не используете бомбу, вы также можете написать compile "junit:junit:4.12", но помните, что jhipster по умолчанию уже использует junit5 для всех тестов.

Что касается импорта бомбы, вы можете сделать это так, как вы предлагали, или попробоватьприменить эту зависимость ко всем подпроектам gradle в вашем основном файле gradle.

0 голосов
/ 26 сентября 2019

Что касается JHipster, помогло немного больше исследований.Согласно этому ответу , в Gradle есть проект , называемый проектом Bill Of Materials, поэтому ...

TL; DR

Добавьтепосле подпроекта

// import JHipster dependencies BOM
implementation platform("io.github.jhipster:jhipster-dependencies:${jhipster_dependencies_version}")

Так что весь блок выглядит как

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"
}

Длинный ответ

Возможно, в будущем, когда я пойму Gradle больше.Или просто отредактируйте этот ответ contribute, чтобы внести

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...