This message was deleted.

the built-in ways are to primarily use plugins or buildSrc; the real question here is how is the offending class loaded?

We have an in-house plugin that we use for doing a bunch of things that we do in several separate projects, so we can avoid duplicating that code. In order to avoid duplicating that code in the plugin's own build, the plugin attempts to use itself by doing something like this:

Class bootstrap() {
    def classpaths = [
        file('src/main/groovy').absolutePath,
        file('src/main/resources').absolutePath
    ]
    String[] classpathArray = classpaths.toArray(new String[classpaths.size()])
    def engine = new GroovyScriptEngine(classpathArray, this.getClass().getClassLoader())
    return engine.loadScriptByName('com/example/plugin/Plugin.groovy')
}

apply plugin: bootstrap()

I think that's probably the cause of this. The

jacocoTestReport

task is from an external plugin that's pulled in by our plugin. Is there a better way for us to share code between our plugin and our plugin's build, so we don't have to duplicate that logic?

Assuming you are publishing that plugin to some repository, you can probably use the last published version to build the next version.

you could take a look at using

includeBuild(".")

and dependency substitutions https://docs.gradle.org/8.1.1/userguide/composite_builds.html#included_build_declaring_substitutions. On paper I think it does what you need

I don't think this will work. That would be endless hen-and-egg recursion. You cannot use what you build to build what you build, because to build what you build you would need to first build what you build to be able to build what you build. See what I mean? 🙂

In this case it's not the building itself that the plugin is trying to use, but things like collecting code coverage data and how to publish to our private maven repository. Perhaps there is a way to factor out the stuff the plugin uses into a sub-project? Can a project use a sub-project as a plugin?

Subproject or not doesn't make a difference for the hen-and-egg problem. You can refactor out the common logic needed for the plugin build and the production build into yet another build though. This build, can be a sub-build of the plugin build, can then have the common logic, but again can of course not use it itself.

@Vampire, What do you mean by "yet another build"?

You have the main build and you have the plugin build. You would add another build that builds the logic used by both builds.

You have the main build and you have the plugin build. You would add another build that builds the logic used by both builds.

Ah, ok, I think I understand what you mean. Our "main build" is really multiple projects, each with its own git repo, each with its own

build.gradle

. The plugin also has its own git repo and its own

build.gradle

. The plugin publishes to our private maven repo, which is how the other projects consume (apply) it. If we split the plugin into two parts, let's call them "plugin-core" and "plugin-complete", both in the same git repo, but two separate builds (ie: two subdirectories each with their own

build.gradle

) is there a way we could have other projects be able to consume "plugin-complete", yet still have access to the "plugin-core" functionality? We don't want to have to publish a separate "plugin-core" artifact — we essentially want "plugin-core" inlined into "plugin-complete". The reason I ask is that one of the bigger things that would go into "plugin-core" is the publishing logic itself, so if we have to publish "plugin-core", we're back to the same chicken and egg problem.

Of course you are, yes. From the consuming point publishing both is soon the correct way, as

plugin-complete

can apply

plugin-core

, so that the consumer gets it applied transitively. Just like

java-library

applies

java

which applies

java-base

and so on. But yeah, the publishing setup you probably need to duplicate.