public class MyPlugin implements Plugin<Project> {
void apply(Project project) {
println "Ow yeah!!"
}
}
Now from within my build.gradle, I want to simply use this:
plugin apply: MyPlugin
but that simply fails with
Could not find property 'MyPlugin' on root project 'project-name'.
On the surface, it looks like I am doing things right, so I am really stuck.
However, if I put the definition of MyPlugin in the build.gradle file of my project, then it works. The point is not to have to define this for every project. And also it contains user specific information, so it belongs in the user’s home directory.
Is there anything preventing you from packaging the plugin and using it as a dependency? The point of a plugin is that it is encapsulated and versioned.
In our current setup, I’m using an init.d script to register a custom build extension implementing the enterprise-wide requirements logic. That works fine.
the script needs to register the maven url, user name and password. All 3 are custom, but script is very short, and very reusable. I do not want to loose flexibility by wrapping it up. With a few scripted lines I can provide and customize access to the repository. For a compiled and published plugin, there is again additional setup and bootstrapping required which I need to avoid.
My only problem is having it available as a plugin in the project.
I was very aware that all those other options were going to be provided. Another option is to externalize the configurable options as properties in ~/.gradle/gradle.properties, while keeping the main logic in build.gradle in the project directory. However, I want to explore finding a direct solution to the issue as posted.
All the actions you mentioned do not require a plugin. If you want them applied to every build, just put them in init script. If you want control, you can put them in an extension object and call it from your builds.