Gradle: зависимости подпроектов, видимые в classpath eclipse - PullRequest
2 голосов
/ 11 октября 2019

Я недавно добавил характер Gradle в наш существующий веб-проект. Сам проект является многоуровневым Java-проектом

Common - DataAccess - Business - Web
                              \- Batch

. Перед тем, как использовать его, мы вручную управляли зависимостями проекта и добавляли только необходимые библиотеки в каждый проект.

Для поддержки нашего проектаструктура, я создал мультипроект gradle:

root
 +-- build.gradle
 +-- settings.gradle
 +-- Common
      +-- build.gradle
 +-- DataAccess
      +-- build.gradle
 +-- Business
      +-- build.gradle
 +-- Web
      +-- build.gradle
 +-- Batch
      +-- build.gradle

Файлы выглядят в основном так (сокращенно, конечно)

Common -> build.gradle

    [...]
    implementation 'javax.money:money-api:1.0.3'
    implementation 'org.slf4j:slf4j-log4j12:1.7.5'
    testImplementation 'org.springframework:spring-test:4.3.13.RELEASE'
    [...]

DataAccess -> build.gradle

dependencies {
    [...]
    api project(':Common')
    implementation 'javax.money:money-api:1.0.3'
    implementation 'org.slf4j:slf4j-log4j12:1.7.5'
    implementation 'org.hibernate:hibernate-core:5.2.14.Final'
    implementation 'org.hibernate:hibernate-jcache:5.2.14.Final'
    implementation 'org.springframework.data:spring-data-jpa:1.11.9.RELEASE'
    testImplementation 'org.springframework:spring-test:4.3.13.RELEASE'
    [...]
}

Бизнес -> build.gradle

dependencies {
    [...]
    api project(':DataAccess')
    implementation 'org.slf4j:slf4j-log4j12:1.7.5'
    implementation 'com.google.guava:guava:25.1-jre'
    implementation 'com.googlecode.java-ipv6:java-ipv6:0.16'
    testImplementation 'org.springframework:spring-test:4.3.13.RELEASE'
    [...]
}

И так далее. Пока проблем нет, сборка gradle выполняется без ошибок.

Но после создания проекта eclipse и файлов classpath с помощью gradle, у проекта Business есть все библиотеки его дочернего проекта в classpath. Поначалу это не большая проблема, но это позволяет разработчикам использовать библиотеки, недоступные для градлинга. Это может привести к ошибкам сборки позже на сервере сборки.

Конечно, я мог бы просто добавить все зависимости, используя api вместо реализации, но должен быть договор, какие вещи использовать на каждом уровне, верно? Нет смысла иметь доступ к библиотекам hibernate / mysql в бизнесе или, что еще хуже, к веб-уровню.

Есть ли способ предотвратить добавление библиотек подпроектов в путь к классам eclipse для gradle?

Обновление 2019-10-16

Пытался пойти по другому маршруту. Вместо API я использовал пользовательскую конфигурацию для импорта подпроекта:

root projects build.gradle: просто пошел другим путем, но я пока не смог решить проблему. В проект сборки root я добавил следующее:

allprojects {
    configurations {
        warOnly
        warOnly.transitive = false
        compile.extendsFrom(warOnly)
    }
    eclipse
    {
        classpath {
            minusConfigurations += [ configurations.runtimeClasspath, configurations.testRuntimeClasspath ]
        }
    }
}

И переключился с

api project(':Common')

на

warOnly project(':subprojectname')

Однако это также, похоже, удаляет всетакже зависимости от compileClasspath. Не осуществимое решение.

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