This message was deleted.
# community-support
s
This message was deleted.
c
the built-in ways are to primarily use plugins or buildSrc; the real question here is how is the offending class loaded?
l
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:
Copy code
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?
v
Assuming you are publishing that plugin to some repository, you can probably use the last published version to build the next version.
a
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
v
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? 🙂
l
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?
Using the last published version is an interesting idea, but has a similar problem. To make our build repeatable, we always use specific versions in our dependencies. To make that more bearable, we have a bot that automatically bumps dependency versions. 1. the bot does not like cyclic dependencies, so a project cannot depend on itself 2. even if it did allow that, the bot would bump the plugin to point at the latest version, which our CI would then publish as a new version, causing the bot to bump it again, etc. Even if we "fixed" issue 2, it also seems like it means we could never fix certain bugs in the next version - it'd have to be the version after that.
v
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.
l
@Vampire, What do you mean by "yet another build"?
v
You have the main build and you have the plugin build. You would add another build that builds the logic used by both builds.
l
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.
v
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.
Well, maybe you can write it in a way that it works hybrid, additionally as script plugin. Then you could maybe "apply from" it in the plugin build.