Как получить доступ к тестам JAR в Gradle в многомодульном проекте - PullRequest
Новая
       3

Как получить доступ к тестам JAR в Gradle в многомодульном проекте

0 голосов
/ 19 марта 2019

У меня многомодульный проект.Из одного из модулей мне нужно ссылаться на тестовые классы из другого модуля.Я попытался настроить так: 

// core project
val testJar by tasks.registering(Jar::class) {
    archiveClassifier.set("tests")
    from(project.the<SourceSetContainer>()["test"].output)
}
val testArtifact by configurations.creating
artifacts.add(testArtifact.name, testJar)

И я пытаюсь сослаться на эту конфигурацию из другого проекта: 

dependencies {
    // other dependencies ommited
    api(project(":core"))
    testImplementation(project(path = ":core", configuration = "testArtifact"))
}

Но эта конфигурация не работает.Компиляция другого проекта не удалась, так как он не видит необходимые классы тестов из core проекта.Понимание зависимости: 

./gradlew :service:dependencyInsight --dependency core --configuration testCompileClasspath

Это дает следующее: 

project :core
  variant "apiElements" [
    org.gradle.usage = java-api
  ]
  variant "testArtifact" [
    Requested attributes not found in the selected variant:
      org.gradle.usage = java-api
  ]

Я изо всех сил пытаюсь понять, как заставить конфигурацию работать так, чтобы я мог скомпилировать тестовые классы проекта service,Работа на Gradle 5.2.1 с Kotlin DSL.

1 Ответ

1 голос
/ 01 апреля 2019

То, что описано выше, работает в командной строке, но не в IDE.

Вот вариант, основанный на управлении зависимостями с учетом вариантов: 

plugins {
    `java-library`
}

repositories {
    mavenCentral()
}

group = "org.test"
version = "1.0"

val testJar by tasks.registering(Jar::class) {
    archiveClassifier.set("tests")
    from(project.the<SourceSetContainer>()["test"].output)
}

// Create a configuration for runtime
val testRuntimeElements by configurations.creating {
    isCanBeConsumed = true
    isCanBeResolved = false
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class, Usage.JAVA_RUNTIME_JARS))
    }
    outgoing {
        // Indicate a different capability (defaults to group:name:version)
        capability("org.test:lib-test:$version")
    }
}

// Second configuration declaration, this is because of the API vs runtime difference Gradle makes and rules around valid multiple variant selection
val testApiElements by configurations.creating {
    isCanBeConsumed = true
    isCanBeResolved = false
    attributes {
        // API instead of runtime usage
        attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class, Usage.JAVA_API_JARS))
    }
    outgoing {
        // Same capability
        capability("org.test:lib-test:$version")
    }
}

artifacts.add(testRuntimeElements.name, testJar)
artifacts.add(testApiElements.name, testJar)

Потому чтоИз правил управления зависимостями, зависящих от варианта, вышеприведенное выглядит как много.Но если бы он был извлечен в плагине, большая часть этого могла бы быть учтена.

И на стороне потребителя: 

testImplementation(project(":lib")) {
    capabilities {
        // Indicate we want a variant with a specific capability
        requireCapability("org.test:lib-test")
    }
}

Обратите внимание, что для этого требуется Gradle 5.3.1.Импорт проекта в IntelliJ 2019.1 правильно связывает зависимости, и тестовый код можно скомпилировать в IDE.

...