Accessing findProject from within a custom plugin


I have been trying to experiment with the Gradle API, however I am having issues understanding some features I would find extremely useful in particular because I am trying to develop a custom plugin for Gradle Native to support my CPP continuous integration system.

I have created a plugin so far that provides a handle to the current project exactly as provided in the plugin example:

public class GreetingPlugin implements Plugin<Project> {
    public void apply(Project project) {
        project.getTasks().create("hello", Greeting.class, (task) -> { // <1>
            task.setRecipient("World");                                // <2>

The issue I am having is that I cannot access the Settings interface as it seems to believe that my plugin methods are called from a static context, as such calling something like the following from within my plugin code throws errors:


Can someone possibly explain firstly how I can call these methods in a plugin from a non-static context, second, if they are the best way to programmatically add another gradle build project via my plugin, and why all my plugin methods, which follow the same structure as the example here: [](http://Plugins Example) seem to believe they are static despite not having a static prefix.


I think it is not possible to access the Settings object from a custom plugin and that access to the settings instance is only permitted from the settings.gradle file.

Quoting the doc:

During build initialisation, Gradle assembles a Project object for each project which is to participate in the build, as follows:

  • Create a Settings instance for the build.
  • Evaluate the "settings.gradle" script, if present, against the Settings object to configure it.
  • Use the configured Settings object to create the hierarchy of Project instances.

Any custom plugin code runs during the configuration phase (which is triggered after the initialisation phase).
You may want to look at init scripts to run code during the initialisation phase.

1 Like

Thank you for the response it was very helpful. After spending some time reviewing init scripts it still does not seem like the ideal situation to be in specifically when there is a plugin architecture already provided. It seems odd that there has to be a system level script to add a project to the build settings of one build configuration because of gradles order of execution particularly when other build configuration tools such as CMake dont seem to have such restriction. Anyway thanks again for the heads up.

If you need to add/remove or reparent projects, you need to create a Plugin<Settings> and apply it in your settings.gradle file. There are not many examples on internet and unfortunately I cannot post mine too…

In short - when the settings script is evaluated, the project structure does not exist yet. Instead you are building a graph of mutable, lightweight project descriptors. These have name, parent, root path, and not much else.

Once the settings are evaluated, the real project graph is created. The project graph structure is immutable from that point on. The ultimate goal of the project evaluation is to produce a task graph, which is frozen are the end of the phase, and executed in the next phase.

Somewhere along the way you define resource model (configs, source sets, etc). These are important, but they are used in the context of tasks and are not driving the process.

If you want to apply your plugin on existing projects without touching their settings or project files, you can use the init script mechanism. If you control the build and environment, I’d recommend that you stay clear of init files until you have a good idea what you want to do and why the init file is the right mechanism for it. If in doubt, ask in this forum.

1 Like


Sorry it was not what you are looking for.
Maybe you should broaden your question in a new topic, state what you currently have, what you want to achieve, and the community might be able to direct you to the best tool for that purpose.

If you prefer to look by yourself, then, it might be worth to have a look at composite builds. This is an interesting feature that can let you choose whether to build coarsely or not your project. Instead of altering the project layout with a plugin, you could define scenarios to build one or several projects at once.

Good luck with your search

1 Like