https://gradle.com/ logo
Join Slack
Powered by
has anyone ever seen this when trying to sign a ma...
# community-support
r
has anyone ever seen this when trying to sign a maven publication :
Copy code
Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':elasticsearch-spark-30:signSpark30scala213Publication' (type 'Sign').
  - In plugin 'org.gradle.plugins.signing.SigningPlugin_Decorated' type 'org.gradle.plugins.signing.Sign' property 'generatorsByKey./Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/classes/scala/spark30scala213.toSign' file '/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/classes/scala/spark30scala213' is not a file.

    Reason: Expected an input to be a file but it was a directory.

    Possible solutions:
      1. Use a file as an input.
      2. Declare the input as a directory instead.

    For more information, please refer to <https://docs.gradle.org/8.14.2/userguide/validation_problems.html#unexpected_input_file_type> in the Gradle documentation.
  - In plugin 'org.gradle.plugins.signing.SigningPlugin_Decorated' type 'org.gradle.plugins.signing.Sign' property 'generatorsByKey./Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/resources/spark30scala213.toSign' file '/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/resources/spark30scala213' is not a file.
🙅‍♂️ 1
v
You try to sign a directory
For example this reproduces your message:
Copy code
val foo by configurations.creating
artifacts {
    add("foo", layout.buildDirectory.dir("foo"))
}
signing {
    useGpgCmd()
    sign(foo)
}
r
but I'm passing a publication. fuck me relying on thirdparty gradle plugins is a no no
digging through the gradle code and the plugin and debugging... getting there
Copy code
> Task :elasticsearch-spark-30:debugSigning
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/classes/scala/spark30scala213
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/libs/elasticsearch-spark-30_2.13-9.0.4-sources.jar
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/libs/elasticsearch-spark-30_2.13-9.0.4.jar
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/classes/java/spark30scala213
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/libs/elasticsearch-spark-30_2.13-9.0.4-javadoc.jar
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/resources/spark30scala213
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/publications/spark30scala213/pom-default.xml
/Users/rene/dev/elastic/elasticsearch-hadoop/spark/sql-30/build/publications/spark30scala213/module.json
for completeness. I finally found the root cause. Seems I need to manually filter out all non jars. doing this like this now
Copy code
private void filterNonJarArtifacts(ConfigurationVariantDetails details) {
        def attribute = details.getConfigurationVariant().getAttributes().getAttribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE)
        if (attribute != null && attribute.name != LibraryElements.JAR) {
            details.skip()
        }
    }
🤷
v
but I'm passing a publication
The point was, that you try to sign a directory, with the configuration was just an example. This reproduces the same using a publication:
Copy code
signing {
    useGpgCmd()
}
publishing {
    val foo by publications.creating(MavenPublication::class) {
        artifact(layout.buildDirectory.dir("foo"))
    }
    signing.sign(foo)
}
(Both examples require that 
foo
as directory exists of course)
r
yeah I understood the problem. I just had no clue where those publicationartifacts came from. as everything seems straight forward just declaring a normal component. but secondary variants like 
classes
fucked that up
Originally I was just wondering if someone had seen that before and maybe there was a known pitfall people had run into before. sparing me hours of debugging but ¯\_(ツ)_/¯ Looking at this it seems it would be a common problem when combing adhoc components and the signing plugin
v
I guess not many people declare own components. I actually wonder that the secondary variant is the problem. It should not be published but only for in-build-usage, shouldn't it? So the signing should not affect it, should it? Otherwise every build that publishes to Maven Central and applies 
java-library
plugin should be affected I guess.
r
Well we use it for having different scala variants for one of our components. That it worked for the main component was the bit I also could not wrap my head around. The joys of inherting sort of abandoned gradle builds 😄
👌 1
3 Views
Open in Slack
PreviousNext
Powered by