> Task :hibernate-gradle-plugin:publishPlugins FAILED
Plugin depends on project ':hibernate-core', but project has multiple Maven publications. Will use first publication (org.hibernate.orm:hibernate-core:6.0.0.Beta1) as dependency in POM.
...
* What went wrong:
Execution failed for task ':hibernate-gradle-plugin:publishPlugins'.
> java.io.FileNotFoundException: /mnt/jenkins-workdir/workspace/hibernate-orm-release/tooling/hibernate-gradle-plugin/src/main/java (Is a directory)
No idea which is the actual problem here, but both show up in the log. And neither really make any sense.
The directory /mnt/jenkins-workdir/workspace/hibernate-orm-release/tooling/hibernate-gradle-plugin/src/main/java absolutely exists
Yes the project in question has 2 publications, and it has had 2 publications all of the other times I have published this plugin.
Any thoughts what the underlying issue might be?
And as a side question, the task logging says it will pick one of the publications, but the task shows FAILED for that reason. The message seems wrong or at best misleading
Anyone? This stops me from being able to publish the Hibernate Gradle plugin fwiw. As we near our next major release (< 2 weeks away) this is becoming much more important. I’m not super comfortable re-enabling this after that final until the next major update.
The directory exists, but the error says “Is a directory”. FileNotFoundExceptions are often a bit misleading as they forward the error from the operating system.
If I for example do a new FileInputStream(aDirectoryHere) on Windows, I get a FileNotFoundException with message “Access denied”.
On Linux you get a FileNotFoundException with message Is a directory, because you cannot read a directory as if it were a file.
Looking at the build scan this happens in PublishTask#addAndHashArtifact, so I’d say you somehow managed to configure the directory tooling/hibernate-gradle-plugin/src/main/java as artifact for publishing.
Ok, I was able to find the cause - but it makes no sense to me.
This plugin has been disabled for a few months due to other reasons. In the interim, the following block was added for all “Java modules” -
configurations {
javadocSources {
canBeConsumed = true
canBeResolved = false
description = 'Configuration for accessing the sources that should be included in the javadoc for the project'
}
}
artifacts {
sourceSets.main.allJava.srcDirs.each { srcDir ->
javadocSources srcDir
}
}
The back-ground here is that we build an aggregated Javadoc over all of the “Java modules” in the project. To avoid use of subprojects {} or other cross-project pollution, the Gradle team suggested using Configurations to share the sources to use. Where we build the aggregated Javadoc I can then simply use, e.g. -
It seems odd that the plugin-publishing-plugin blindly assumes that any/all consumable Configurations are part of the plugin. Or am I misunderstanding what happens here? This Configuration is unequivocally the reason for the failure. Once I removed it, publishing worked fine.
Since it is working (thanks @Vampire !) this is not critical, just something I’d really like to understand -why this happens, and whether it is a bug in the plugin-publishing-plugin or something I need to be cognizant of in other endeavors.
Thats actually a rather complex and legacy story.
I’m not fully sure I remember it fully correctly, but it is something like this:
There is the archives configuration that is mainly used for the old maven plugin.
Every artifact in that configuration was / is considered a production archive.
The base plugin which is basically applied to almost all Gradle projects attaches all artifacts of non-hidden configurations to the archives configuration.
Something like that.
So you could probably simply declare your configuration as hidden.
But I looked a bit around in the sources of the task and plugin and actually if you apply the maven-publish plugin, a different code path is taken that does not use the archives configuration, but uses the variant-aware mechanism with the java-runtime variant, so then you shouldn’t have that problem. So if you additionally apply the maven-publish plugin and configure the publish task it adds instead of creating your own, I think your problems should be solved, at least I came past that error when trying.
Additionally you might consider updating the plugin version. You have 0.16.0 but current is 0.20.0.
It for example protects against accidentally pushing a transitive dependency on a log4shell vulnerable log4j version. Besides that having log4j-core in the dependencies is a bug per-se already imho.
Yes, sorry. I wrote task. but meant configuration..
Regarding maven-publish, how would I configure the publish task? And to be clear, this plugin module is not published in the normal sense like the other modules are (to OSSRH). I assume you meant configure it to work locally, but just for full disclosure.
Yes, sorry. I wrote task. but meant configuration. .
Then yes
Regarding maven-publish , how would I configure the publish task? And to be clear, this plugin module is not published in the normal sense like the other modules are (to OSSRH). I assume you meant configure it to work locally, but just for full disclosure.
If you apply the maven-publish task, it automatically registers a publish lifecycle task.
(actually it automatically applies the publishing plugin which registers the publish lifecycle task)
This task depends on all publishing tasks that publish to remote repositories.
So as long as you don’t define remote repositories to publish to (for example if you want to publish to maven central too), it will not depend on any tasks.
So you just apply the maven-publish plugin and remove the task from task publish to configure the existing publish task instead of creating a new publish task.
