From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

I don't think so.
If a plugin is not present this can change the whole semantics of the build.
I strongly recommend you not try to do that.

Having said that, you could probably use the legacy way to apply the plugin and before applying check whether the class of the plugin can be found.

But really, don't do that. :slightly_smiling_face:

let’s say that `my-awesome-plugin` is in a private repo that i need vpn to login to.
and this plugin does not affect the build in any way, but gives extra tasks that my org needs in the ci/cd.
and i don’t need it/can’t get to the private repo while development .
i know it’s a very bad practice. but its still something i was wondering about

you could try and copy the plugin Maven Local, and add Maven Local as a plugin repository?

i guess so.
but it was more of a theoretical question.

do you have access to the `my-awesome-plugin` source code? You could check it out and set up a <https://docs.gradle.org/current/userguide/composite_builds.html|composite build> (add it as an `includedBuild()`), then Gradle should substitute it

or maybe write some <https://docs.gradle.org/current/userguide/resolution_rules.html#sec:module_replacement|complicated custom resolution rule> that would replace the `my-awsome-plugin` <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers|plugin marker artifact> with the Gradle Base Plugin marker artifact

am i doing this rigght?
in the repositories:
```mavenLocal {
            uri("/tmp/derp/location")
        }```

Maven Local is a fixed location, which defaults to `$USER_HOME/.m2`. You can change it, but not via Gradle configuration.

there’s a few ways of changing it, I think one is via a system property, and another is in some Maven settings.xml… Either way, Gradle should pick that up automatically

i’m looking into this <https://stackoverflow.com/questions/32107205/gradle-does-not-use-the-maven-local-repository-for-a-new-dependency|so question>

if you wanted you could just manually add the repository directory, using a regular `maven {}` definition

```repositories {
    maven {
        url = file("/path/to/repo")
    }
}```
but if you’re using Kotlin DSL, I’d define it like this, and then it’s usually a good idea to add a name

```repositories {
    maven(file("/path/to/repo")) {
      name = "MyLocalRepo"
    }
}```


&gt; and this plugin does not affect the build in any way, but gives extra tasks that my org needs in the ci/cd.
Then you could just do what I said roughly.
Use the legacy applying by adding to build script classpath and calling `apply` and make both actions in an `if` that checks somehow whether that repository is available or not. But make sure you don't have to wait for some "long" connection timeout when not in VPN.

Having that plugin in some local repository might be bad if it then builds differently because you have different plugin version.

But actually, you should probably just not apply that plugin at all in the regular build

Instead make your CI/CD have some init script that applies that plugin, so it is exactly applied when CI/CD is used.

That also saves you the time for applying it even when building with VPN