Vampire commented on code in PR #277:
URL: https://github.com/apache/groovy-geb/pull/277#discussion_r2179451168
##########
settings.gradle:
##########
@@ -23,6 +23,12 @@ plugins {
// updating this, check the compatibility from
https://docs.gradle.com/enterprise/compatibility/#develocity_compatibility and
https://develocity.apache.org/scans.
id "com.gradle.develocity" version "3.18.2"
id 'com.gradle.common-custom-user-data-gradle-plugin' version '2.0.2'
+ // The Ratpack server providing the gem repository uses classes from
+ // jakarta.activation-api.jar brought in here by
org.kordamp.gradle.oci-build-cache
+ // but the classes in there cannot work properly as classes from
+ // the activation implementation are missing, so bring the plugin
+ // to the classpath here to fix compatibility problems
+ id 'org.asciidoctor.jvm.gems' version '4.0.4' apply false
Review Comment:
It's not really smelly, just the usual conflict resolution work you need to
do with Gradle in such situations.
Noone is doing a bad job in declaring dependencies I'd say.
The `org.kordamp.gradle.oci-build-cache` plugin declares the API artifact
that it compiles against.
By being in the settings classpath, this API artifact lands in a class
loader that is a parent class loader.
And the implementation classes that are needed are otherwise in the child
classloader where the `org.asciidoctor.jvm.gems` plugin brings them in so the
API classes cannot find the implementation classes.
It would be the same situation if a settings plugin brings in an older
version of a library and a project plugin needs a newer version of a library to
work properly.
Or a plugin on the root project brings in an older version of a library and
a subproject plugin needs a newer version of a library to work properly.
Unless all plugins shade and relocate the dependencies that they use (and
I'm not a fan of that tactic for various reasons) there is not much any of the
plugins could do about these situations, but it is in the responsibility of the
consuming build author to bring things that need to be on the same classloader
to the same classpath like I did here. :-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
