Any work around in 1.11 for http://issues.gradle.org/browse/GRADLE-2407?


(sunckell) #1

Prior to 1.11 (1.5 and 1.8) we were able to put the following in the init.gradle in our custom gradle version:

allprojects { project ->

libs.each {

project.plugins.pluginRegistry.classLoader.addURL it.toURI().toURL()

}

}

Once we went to 1.11 were are getting the following during build. No such property: classLoader for class: org.gradle.api.internal.plugins.DefaultPluginRegistry

Thanks…


(Luke Daley) #2

Hi,

This is internal API so can and will change at any time without notice.

As for finding a replacement, it depends on what you’re trying to achieve.


(sunckell) #3

We created a custom distribution (with separate plugins, dependencies for those plugins). We were trying to keep the custom code separate from the internal dependency lib tree.

for example: ${GRADLE_USER_HOME}/wrapper/dists/custom-gradle-1.8-0.12/bla-bla-bla/gradle-1.8

./bin ./init.d ./lib ./media ./custom-lib

Without the above code we are unable to get our custom-lib files on the classpath.


(Peter Niederwieser) #4

See ‘samples/customDistribution’ in the ‘gradle-bin’ download for how to add your dependencies to the build script class path.


(sunckell) #5

Still seem to be having problems…

I took a look at the sample/customDistribution, but that doesn’t seem to be the perfect fit with what I am trying to do.

I’ll try and explain a bit further…

We have a custom distro with custom plugins.

From the sample/customDisribution examples, the custom plugins and dependencies for the plugins are placed into the init.d/libs directory. Our custom-plugins are compiled to custom-plugins.jar, with all it’s dependencies as well…

I am trying to use the custom plugins in a custom-init.gradle so that they are applied to all projects.

I found: http://forums.gradle.org/gradle/topics/best_approach_to_apply_custom_plugin_to_root_project_via_init_script_in_a_custom_distribution

which lead me to:

which references the http://issues.gradle.org/browse/GRADLE-2407 bug BTW.

Luke shows a work around for custom-init.gradle, but the plugin class in contained with in the init.gradle file.

Our plugins are not contained in the init.gradle file, but within the jar in the init.d/ligs/custom-plugins.jar.

I cannot seem to find a way to apply the plugins in the init.gradle file, everything comes up with either Plugin ID not found or if I use the extensions.create() the class isn’t found.

custom-init.gradle

rootProject {
    extensions.create("myPlugin", com.foo.bar.MyPlugin, buildscript)
}
  • What went wrong: Could not find property ‘com’ on root project wrapper. << points to the above line in the custom-init.gradle file for extensions.create.

(Peter Niederwieser) #6

Our custom-plugins are compiled to custom-plugins.jar, with all it’s dependencies as well…

I don’t see how this makes a difference.

I am trying to use the custom plugins in a custom-init.gradle so that they are applied to all projects.

OK, that’s something you didn’t mention earlier. Until Gradle-2407 gets resolved, you may have to apply the plugin in the build(s) rather than the init script. (I’m not aware of another solution.) http://forums.gradle.org/gradle/topics/how_can_you_use_an_init_script_to_specify_a_repo_dependency_for_a_plugin_jar_but_allow_version_to solves a different problem, and still requires the plugin to be applied in the build.


(sunckell) #7

The idea of this approach was to be able to enforce governance and standards for developers which use our custom-distro.

As in, write plugins that checks for certain standards (such as version or naming standards). Then have them be enabled without developer intervention (or preventing developer removal.)

How would one enforce these types of standards, if not through plugins in a init.gradle fashion?


(Peter Niederwieser) #8

Until GRADLE-2407 gets resolved, one tiny bit of developer intervention may be required, which is to add ‘apply plugin: “mycompany-standards”’ to the root project’s build script (i.e. once per build). This isn’t perfect, but shouldn’t pose serious problems either.


(Luke Daley) #9

Another thing you can do is add the dependencies to the init script classpath and apply through that instead of the project classpath.

initscript {
  dependencies { classpath files(… whatever …) }
}
  allprojects { apply plugin: PluginType }

Note that ‘PluginType’ is a ‘Class’ literal object and not a plugin id. Using a plugin id won’t work with this mechanism.