Hi there. I have developed a binary plugin and published it on my

mavelLocal()

repo. I now intend to call this plugin for projects, ideally without modifying their

build.gradle

file. Apparently the most reasonable way of doing this is placing the plugin's

apply

in an init file (there was some talk in github about implementing something else to be able to call plugins from the CLI, but as far as I can see it didn't get anywhere) Now, calling it from the target project's

build.gradle

file seems to work fine, but when I try to do

apply plugin: 'org.konveyor.java.plugin:konveyor-download-sources:1.0-SNAPSHOT'

from the init file, it fails. My init file looks like this:

buildscript {
    repositories {
        mavenLocal() // Repository where your plugin is hosted
    }
    dependencies {
        classpath 'org.konveyor.java.plugin:konveyor-download-sources:1.0-SNAPSHOT'
    }
}

apply plugin: 'org.konveyor.java.plugin:konveyor-download-sources:1.0-SNAPSHOT'

Any help would be appreciated, thanks!

apply plugin:

takes a plugin id, not an artifact coordinate

@ephemient thanks for the info re. the plugin id

I cannot speak to what your goal is, nor can my light searching find this plug in available, so this is based on assumption of what the plugin itself is

org.konveyor.java.plugin

. But I did get this concept working with an init script before with other plug ins.

if (gradle.getParent() == null) {
  beforeSettings { settings ->
    settings.buildscript.repositories { mavenLocal() }
    settings.buildscript.dependencies.add("classpath", "org.konveyor.java.plugin:konveyor-download-sources:1.0-SNAPSHOT")
  }
  settingsEvaluated { settings ->
    if (!settings.pluginManager.hasPlugin("org.konveyor.java.plugin")) {
      settings.pluginManager.apply("org.konveyor.java.plugin")
    }
  }
}

Hey @Daniel B Duval, thanks for your reply, yeah it's a plugin I'm developing to be able to fetch the source JARs of gradle projects. I will try that out, thank you!

don't the project and settings buildscript classpaths extend the init buildscript classpath?

I'm quite ignorant in terms of Gradle, I have barely used it

@ephemient - the way I understand this is that there’s a desire to have all gradle projects on a machine to this plug in without having it in their build scripts. If I read that right, the above was a solution I put in place for spinning gradle based projects in our cloud dev environment (machines are ephemeral and can be destroyed all the time). This solution brought in the init script to enforce certain behaviors such as apply a plug in like gradle enterprise / devlocity by just using the cloud based prodcut.

sure, I just mean it could possibly be

buildscript {
    repositories {
        mavenLocal()
    }
    dependencies {
        classpath "..."
    }
}
settingsEvaluated { // or rootProject or allprojects, depending on the desired target(s)
    pluginManager.apply("...")
}

instead of mucking with the child buildscripts, if the classpath is inherited

That’s a good way, I guess it’s a question of the goal: Are you trying to enforce that anyone using any machine on any build does this or is it just with the project. As I mentioned, my solution was a way of injecting the gradle enterprise/devlocity plug-in to any gradle project using our cloud engineering environment if they have not added it to their project. It does need to be part of the set process up to where the init script gets copied over to/placed into the needed place for it to work out of the box. Otherwise it’s a repeat each time manually, which may lose any value add in that screnario.

@Daniel B Duval thank you man, it looks like its working with your solution 🙂

well that means you built a project plugin and you're trying to apply it to settings (because that's what Daniel's snippet does)

I should also point out that my example is based on putting it in

$GRADLE_USER_HOME/init.d/

path. Shouldn’t make a difference, but I was trying to just build an environment for anyone and have a set of plug-ins applied by using the set up I had defined.

that seems outdated; the simpler solution now is

dependencyResolutionManagement {
    repositories {
        maven {
            ...
        }
    }
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
}

in

settings

Should be any difference between placing it in

init.d

or anywhere else and doing

---init-script

?