How can one change the version of dependency of a Gradle plugin as an end-user? For example, the https://github.com/radcortez/openjpa-gradle-plugin depends on a certain version of OpenJPA, and I want it to run with a more recent one.
Apparently that particular Gradle plugin creates an openjpa “configuration” (whatever that is…), and it ignores the OpenJPA dependency I put on buildscript dependencies.
I guess I’m basically looking for the Gradle equivalent of you know how in Maven you can put <dependencies> into a <plugin> to override that particular single plugin’s own dependencies - that can sometimes come in handy.
Generally, plugins would create a Gradle configuration with a default dependency version and then allow you to specify any version that you want, if you want to override it. This is a configuration like would be used in the dependencies block instead of implementation or similar:
The “configuration” I see in the plugin you’ve referenced looks to be an extension though, so it’s just configuration in the general sense, not the Gradle concept of a configuration.
Normally, if a plugin is compiled and uses a dependency, overriding the buildscript classpath would be fine. However, in this plugin, an attempt was made to load classes from the compile classpath of the project you’re using it in. I don’t have an easy project to test this plugin with, but if that functionality is working, you would upgrade the version you’re using by using a new version in your application, not by manipulating the buildscript classpath.
This refers to the configuration used in most of the tasks. The plugin is also creating an openjpa configuration in the metamodel task, but too late to use it as mentioned above.
this (added in this project’s fineract-provider/dependencies.gradle) doesn’t seem to work:
Could not find method openjpa() for arguments [org.apache.openjpa:openjpa:2.4.3] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Right, but what’s confusing me is that that’s actually already done - that project has two OpenJPA dependencies, one in its buildscript classpath (in fineract-provider/build.gradle) and one in its runtime dependencies (in fineract-provider/dependencies.gradle) - yet it still seems to pick the wrong version.
This absolutely won’t work now due to how the plugin is written. I read your question as, “I know the plugin is wrong, but how is this supposed to work, so that I can file the appropriate issues or create PRs with the plugin?” The ways this is normally done only works if the plugin author writes their implementation to support it.
When I quickly looked at the implementation, I believe the the metamodel task was looking specifically at the compile configuration, not runtime, but I didn’t actually look at any documentation for what each task was intended to do.
In any case, these weren’t meant to be ways to make this work with a current version of the plugin. The plugin needs some enhancements to work more conventionally and I thought you were conceptually asking what the author should do. The Gradle equivalent of the Maven concept you mentioned doesn’t work here because of implementation, but it’s not Gradle convention really either.
As I understand it, you need to configure the plugin to use a different version of openjpa than what it defaults to. And according to the documentation, you can do it like this:
However, if you do, the plugin itself explodes with a NoClassDefFoundError when constructing this “metamodel” extension due to the fact that it uses an internal Gradle class that has been moved/removed in more recent versions of Gradle (issue #8).
As a temporary work-around until the plugin is fixed, you can try either of the following in your own project:
configurations.all {
resolutionStrategy {
force "org.apache.openjpa:openjpa:$openJPAVersion"
}
}
I don’t think the openjpa declaration in the buildscript dependencies is used at all. Like jjustinic says, the “enhance” task selects the version from your own project’s compile classpath (currently 2.4.3), whereas the “metamodel” task uses the above extension property, defaulting to 2.4.2 if none is found.
The versions of openjpa shown in the first (3.0.0) and second (2.4.3) outputs look different to me, so I’m not sure what you mean that it doesn’t seem to work