I’ve got an use case for what the subject describes. I’ve got a build system that should treat a source repository as a black box, that is, invoke the build without modifying the sources. Additionally I need extra information provided by plugins that may not have been configured in the build, such as jdeps and jdeprscan.

In the Maven world this is as easy as invoking mvn groupId:artifactId:version:targetId; provided the plugin can be resolved from the repositories configured in the POM file (AFAICT). Sadly, there’s no equivalent syntax found in Gradle.

The first alternative I thought of was to create another script with the additional plugin config in place, importing the main build file, then instructing gradle to use the new build file, such that

Then invoke gradlew -b my-custom-build.gradle jdeps which unfortunately fails. The next option was to append the required customizations to the main build file, but this will cause trouble depending on how the main build file defines plugins.

If it uses buildscript then all is OK as you can have multiple buildscript blocks. Still feels odd somehow.

If it uses plugins and customizations use buildscript then results in Failure with the following error printed to the output "all buildscript {} blocks must appear before any plugins {} blocks in the script

If it uses plugins and customizations use plugins too then it results in Failure again with the following error printed to the output "only buildscript {} and other plugins {} script blocks are allowed before plugins {} blocks, no other statements are allowed

I think the best way to invoke build logic without touching sources would be using an init script. With shipping init scripts in a init.d folder in the distribution or gradle user home these get also executed automatically.

Indeed. I was getting an error stating Plugin with id 'org.kordamp.jdeps' not found. with a different approach until I saw your remark for fully qualified class.

On the plus side this approach works regardless of how the build has defined plugins (plugins or buildscript block). On the down side the inconsistency of not being able to use the plugin id with the resulting error message being a bit obscure.

It would be great if init scripts would have access to plugin ids, as that data already resides in resource files available in the classpath.