I am building a copy spec that includes the following:
from publishing.publications.withType(MavenPublication)*.artifacts*.file
Which leads to:
* What went wrong:
A problem occurred evaluating project ':release'.
> Could not find property 'file' on [DefaultMavenArtifact_Decorated jar:null, DefaultMavenArtifact_Decorated jar:sources].
Any pointers why? MavenArtifact is documented to expose getFile() -> https://docs.gradle.org/current/javadoc/org/gradle/api/publish/maven/MavenArtifact.html#getFile()
Or perhaps there is a better way to collect all “publish artifacts” for builds using the new publishing? I tried the “old way” as well:
from configurations.archives.allArtifacts.files
But only the main jar is added here, not sources, etc
Remember that MavenPublication.getArtifacts()
is in turn a collection. You are trying to collect the file
property on a data structure that looks like [[foo.jar],[foo-sources.jar]]
. You’ll need to do something like this:
publishing.publications.withType(MavenPublication)*.artifacts.collectNested { it.file }
Also, a better way of accomplishing this without having to worry about configuration order is:
task copyPublications(type: Copy) {
publishing {
publications.all {
artifacts.all {
dependsOn it
from it.file
}
}
}
into "$buildDir"
}
Thanks Mark. I wish I could do it how you do it in that second piece, but this is being defined in the distribution extension, so there is no direct thing there to attached dependsOn stuff. But I will definitely give the other piece a try.
I just misunderstood the spread-dot operator.
The dependsOn
bit is necessary here because otherwise we have no way of modeling that the CopySpec
requires the associated tasks to be executed in order to create that file. Since you are configuring a CopySpec
and not a Task
you could solve this problem by essentially “wrapping” the artifact as a Buildable
.
from files(it.file) { builtBy it }
This should create an implicit dependency between whatever consumes the CopySpec
and the tasks that create the publication artifacts.
At the moment I just do a series of implicit dependsOn for a “virtual task” and then say that each dist task depends on the virtual task. I will look into your builtBy suggestion, as I hated specifying all this twice, and this would remedy that.