如果应用了Java插件，Gradle将无法在合成版本中找到zip工件

Question

我有一个创建zip工件的Gradle项目。我通过定义了工件artifacts.add('default', zipTask)。我通过将该项目添加到另一个项目，includeBuild并使用zip作为依赖项（dependencies { myConfiguration 'org.example:testA:+@zip' }）。到目前为止，一切都很好。有用。

当我将插件添加java到第一个项目时，问题开始。由于某些原因，它阻止Gradle查找zip工件。错误是：

Execution failed for task ':doubleZipTask'.
> Could not resolve all files for configuration ':myConfiguration'.
   > Could not find testA.zip (project :testA).

为什么？如何解决？

完整的例子：

项目 testA

settings.gradle：

rootProject.name = 'testA'

build.gradle：

plugins {
    id 'base'
    // Uncomment the line below to break the zip artifact
    //id 'java'
}

group = 'org.test'
version = '0.0.0.1_test'

task zipTask(type: Zip) {
    from './settings.gradle' // just so the zip isn't empty
}

artifacts.add('default', zipTask)

项目 testB

settings.gradle：

rootProject.name = 'testB'

// This line may be commented out in some cases and then the artifact should be downloaded from Maven repository.
// For this question it should be always uncommented, though.
includeBuild('../testA')

build.gradle：

plugins {
    id 'base'
}

configurations {
    myConfiguration
}

dependencies {
    myConfiguration 'org.test:testA:0.0.0.+@zip'
}

task doubleZipTask(type: Zip) {
    from configurations.myConfiguration
}

---

更新1

我在末尾添加了一些诊断代码build.grade：

configurations.default.allArtifacts.each() {
    println it.toString() + ' -> name: ' + it.getName() + ', extension: ' + it.getExtension()
}

并在带有java插件的版本中打印：

ArchivePublishArtifact_Decorated testA:zip:zip: -> name: testA, extension: zip
org.gradle.api.internal.artifacts.dsl.LazyPublishArtifact@2c6aaa5 -> name: testA, extension: jar

但是，我不确定其他工件是否会破坏某些东西。

当我自己添加第二个工件时，这似乎不是问题。

---

更新2

也许zip文件不是我意图的最佳体现。毕竟，我可以在一个项目中构建与Java相关的文件，然后在另一个项目中压缩它们。但是，该问题也适用于war文件。（War插件内部使用Java插件，因此无法单独运行。）

Answer 1

The issue seems to be a bug in Gradle where the composite build and reference to artifacts are broken.

Some discussion is here: https://discuss.gradle.org/t/composite-build-cant-use-included-artifact-in-buildsrc-build-gradle/24978

Bug report: https://github.com/gradle/gradle/issues/3768

A workaround would be to move the artifact dependency to a task dependency:

plugins {
    id 'base'
}

configurations {
    myConfiguration
}

dependencies {

}

task doubleZipTask(type: Zip) {
    dependsOn gradle.includedBuild('testA').task(':zipTask')
    from configurations.myConfiguration
}

Answer 2

以下设置应适用于 Gradle 5.6（当使用其他属性时，它可能也适用于以前的版本）。除了 指示的更改之外，它大部分与您的原始设置相对应XXX。

\n\n

项目testA

\n\n

settings.gradle:

\n\n

rootProject.name = \'testA\'\n

\n\n

build.gradle:

\n\n

plugins {\n    id \'base\'\n    // Uncomment the line below to break the zip artifact\n    //id \'java\'\n}\n\ngroup = \'org.test\'\nversion = \'0.0.0.1_test\'\n\ntask zipTask(type: Zip) {\n    from \'./settings.gradle\' // just so the zip isn\'t empty\n}\n\n// XXX added an attribute to the configuration\nconfigurations.default.attributes {\n    attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE,\n              project.objects.named(LibraryElements, \'my-zipped-lib\'))\n}\n\nartifacts.add(\'default\', zipTask)\n

\n\n

项目testB

\n\n

settings.gradle:

\n\n

rootProject.name = \'testB\'\n\n// This line may be commented out in some cases and then the artifact should be downloaded from Maven repository.\n// For this question it should be always uncommented, though.\nincludeBuild(\'../testA\')\n

\n\n

build.gradle:

\n\n

plugins {\n    id \'base\'\n}\n\nconfigurations {\n    // XXX added the same attribute as in the testA project\n    myConfiguration {\n        attributes {\n            attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE,\n                      project.objects.named(LibraryElements, \'my-zipped-lib\'))\n        }\n    }\n}\n\ndependencies {\n    myConfiguration \'org.test:testA:0.0.0.+@zip\'\n}\n\ntask doubleZipTask(type: Zip) {\n    from configurations.myConfiguration\n}\n

\n\n\n\n

我已经在使用和不使用插件的情况下测试了此设置java。I\xe2\x80\x99ve 还测试了发布到 Maven 存储库并让其testB从那里获取其依赖项，而不是从testA. 添加对( )testB的 JAR 工件的额外依赖也有效。testAmyConfiguration \'org.test:testA:0.0.0.+@jar\'

\n\n

关于（我相信）正在发生的事情的一些解释：Gradle 需要一种自动确定其中的本地组件/工件testA可以用来替换testB.

\n\n

\n
• 如果不应用该java插件，则只有一个组件/工件，我的猜测是 Gradle 然后会毫不费力地选择该单个组件/工件。
\n
• 正如您所看到的，通过应用该java插件，另一个工件被添加到testA. 现在 Gradle 应该选择哪一个？人们期望它会查看依赖项上指定的文件扩展名，testB但\xe2\x80\x99t 似乎并非如此。看起来 Gradle 在替换依赖项时实际上并不是在工件级别工作，而是在模块/组件级别工作。您可能会说我们只有一个组件和两个工件，因此选择一个组件应该很简单。但看起来我们实际上有同一组件的两个变体，而 Gradle 想要选择这些变体之一。在您自己的testB设置中，没有任何线索可以告诉 Gradle 选择哪个变体；所以它失败了（带有公认的错误/误导性错误消息）。在我更改的testB设置中，我提供了线索：我告诉 Gradle 我们想要具有特定属性且值为的变体my-zipped-lib。由于 I\xe2\x80\x99 在 的已发布配置上添加了相同的属性testA，Gradle 现在能够选择正确的变体（因为只有一个具有所需的属性）。依赖项的文件扩展名在第二步中仍然相关：一旦 Gradle 选择了组件变体，它仍然需要选择正确的工件 \xe2\x80\x93 但只有这样。
\n

\n\n

请注意，我们\xe2\x80\x99 实际上正在研究当今复合构建支持的边缘。另请参阅Gradle 问题 #2529，其中指出发布非 jar 工件的 \xe2\x80\x9c 项目\xe2\x80\x9d 没有得到很好的支持。当我第一次看到你的问题时，老实说，我认为我们\xe2\x80\x99d在这里运气不好\xe2\x80\xa6，但似乎\xe2\x80\x99s有一种方法可以再次靠近边缘一点；- ）

\n\n\n\n

在评论中，提出了为什么在应用插件时添加多个自定义工件java会破坏构建的问题。正如我上面尝试解释的那样，xe2x80x99 不是多个工件的问题，而是多个组件变体的问题。IUIC，这些变体源于配置上的不同属性。当您不添加此类属性时，您将不会有不同的组件变体。但是，Java 插件确实添加了此类属性，从而导致项目（/组件）中出现不同的组件变体。如果您\xe2\x80\x99感兴趣，您可以通过向您的 中添加类似以下内容来查看不同的属性build.gradle：

\n\n

configurations.each { conf ->\n    println "Attributes of $conf:"\n    conf.attributes.keySet().each { attr ->\n        println "\\t$attr -> ${conf.attributes.getAttribute(attr)}"\n    }\n}\n

\n\n

现在在哪里以及何时添加哪些属性？这取决于您的设置。我不会\xe2\x80\x99盲目地为所有配置添加属性，希望\xe2\x80\x99能神奇地解决问题。虽然它可能有效（取决于您的设置），但它\xe2\x80\x99d 肯定不干净。如果您的项目设置像您的问题所暗示的那样复杂和/或特殊，那么更深入地思考您需要哪些配置以及它们应该携带哪些属性可能是有意义的。如果您还不太熟悉 Gradle 中配置的这些细微差别，我上面链接的Gradle 文档页面的第一部分可能是一个很好的起点。是的，我同意这样的逻辑最好存在于 Gradle 插件中。

\n