This message was deleted.

You should not use

mavenLocal

if possible or at most with using a repository content filter, because

mavenLocal

is broken by design. Better use a composite build. To get the "as close as possible to the experience as simply writing a

build.gradle

file" write your convention plugins as precompiled script plugins as documented at https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins

Unfortunately this just leaves me with more questions than answers, I'd already read this I've created the minimal sample repos/files above with the hope that someone might be able to suggest a few lines of code which demonstrates it - a Github repo like this is exactly what I would have hoped for from the docs

I've created the minimal sample repos/files above with the hope that someone might be able to suggest a few lines of code which demonstrates it

Those repos are not accessible, actually.

a Github repo like this is exactly what I would have hoped for from the docs

https://github.com/jjohannes/idiomatic-gradle might be interesting for you, but it might also be way more complex than you actually need and want.

as it appears they require the "common" repo to be checked out locally already,

Yes, that's correct.

which may be out-of-date

Well actually it is usally the other way around. By requiring to manually publish the dependency to some repository or local repository or

mavenLocal()

, you always have to go to that module, change something, publish it manually and then use the new version. With a composite build you can just change something in

common

and run the consumer build which will automatically build and use the dependency. Both have their pros and cons liek always of course, but usually a composite build is much more convenient to work with, at least while developing changes.

I'm curious as to what you mean by "mavenLocal is broken by design" - wonder if that contributes to any of my problems so far.

Here are some of the problems documented: https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local

Silly me, the repos are visible now 🙂

A prohibitive limitation of "precompiled script plugins", it seems - it forces you to put the dependency versions in the depending projects

No, why should it? Believe me, precompiled script plugins is exactly what you want. And yes, it is more like a 2 minute effort. You basically apply the plugin for the DSL you want to use and configure the publishing using

maven-publish

. Then you can write your convention plugins almost like normal build scripts.

Well, I've spent hours so far.

That is one of the "*almost* like normal build scripts" points. In the precompiled script plugin you use it without version. You can define the version in the consuming project, but that's not the idiomatic way. It is an implementation dependency of your convention plugin. So you declare it as implementation dependency in the build script for your convention plugin, so in

common/build.gradle(.kts)

buildscript {
  repositories {
    maven {
      url "<https://plugins.gradle.org/m2/>"
    }
  }
  dependencies {
    classpath "com.diffplug.spotless:spotless-plugin-gradle:6.18.0"
  }
}

This is what I had in the main project, but

buildscript

is not allowed in Groovy script plugins. I'm sure there's another way to express it (I've tried multiple)

Have a look at Jendrik's repository I linked you to. As I said, it is most likely more complex than you need it, and it uses composite builds, but whether you use the project as composite build or publish it to a repository does not make much difference, except for the

maven-publish

configuration to actually publish it. The actual implementation and usage is the same.

I did already take a look, you're certainly right about it being too complex for me

This is what I had in the main project, but

buildscript

is not allowed in Groovy script plugins. I'm sure there's another way to express it (I've tried multiple)

Well, you maybe didn't read what I wrote two message ago 🙂

Definitely did, maybe just not understanding it.

No, you said you tried to add it to the

buildscript

block of the precompiled script plugin. That is not even similar to what I said. 😉

So you declare it as implementation dependency in the build script for your convention plugin

I'm sure I'm just stupid, but this reads to me like the same thing. Unwrapping the

buildscript

block also yields

org.gradle.api.plugins.UnknownPluginException: Plugin with id 'com.diffplug.spotless' not found.

No, "the build script or the project building your convention plugin" is not nearly the same as "the

buildscript

block inside your convention plugin". I even told you the exact file where you put and what you put in there to make sure you don't misunderstand like that. 😉

Appreciate the red penciling

As this will give you "configuration classpath not found" and I said "implementation dependency", not "classpath dependency", no 🙂

I'll leave this thread in case anybody feels free to hack on the git repos I spent some time preparing (seeing as it sounds like a ~2 min task to demonstrate) - unfortunately I've done so much reading of documentation, examples, and conversations, that everything just feels like disconnected advice at this point. Seeing a minimally working example is the only path forward to integrating my understanding at this point

Not sure what the problem is. Take your last code block, replace

classpath

by

implementation

, put that to the

common/build.gradle(.kts)

build script, then use the plugin without version in your convention plugin, that's it.

Added the changes: https://github.com/ndg-github/common/blob/main/build.gradle

> Failed to apply plugin 'common'.
   > org.gradle.api.plugins.UnknownPluginException: Plugin with id 'com.diffplug.spotless' not found.

That's because you nested your plugin too deep. By having

common/buildSrc

you have yet another standalone build that is built separately to then by applied in

common/build.gradle

which is not what you actually want. You want your

common.gradle

in

src/main/groovy

and apply

groovy-gradle-plugin

in

common/build.gradle

. Then you can apply

common

in your

appX

builds. Besides that

common

is a bad name, custom convention plugins should always have some namespace (a dot in the name, or a package declaration in the precompiled script plugins). Namespaceless plugin IDs should be reserved for Gradle built-in plugins.

Thanks, yes,

common

was just quickly picked for the purposes of this PoC - not what I would keep. So I've moved the apply of

groovy-gradle-plugin

into the

common/build.gradle

(well,

/build.gradle

, being the repo root) Are you saying to

mv buildSrc/src/main/groovy/common.gradle src/main/groovy/common.gradle

essentially? Doing that yields

Plugin [id: 'common'] was not found in any of the following sources:

Yes I do and you of course remove applying

common

in

common/build.gradle

(just using

common/

to make sure I'm not talking about

appX/build.gradle

). You want to apply

common

in

appX/build.gradle

, not in

common/build.gradle

.

That makes sense to me now. I've explored enough bad routes that I've lost sense of good and bad

Just imagine

common

as a standalone version of

buildSrc

, which actually is exactly the case. So basically if you copy

buildSrc

out, rename it to

common

and add publishing configuration you are almost where you want to be.

Okay, so I've published to mavenLocal (https://github.com/ndg-github/common/blob/main/build.gradle) And a failed access from: https://github.com/ndg-github/app1/blob/main/build.gradle Now I'm not surprised it is failing to find the plugin, but I'm not quite sure on what the solution needs to look like

No,

common

is fine, you just did not specify the version of `common`to apply in

app1

Added that separately since my last message; I'm thinking I need something like this in `app1/settings.gradle`:

pluginManagement {
    repositories {
        mavenLocal()
    }
}

Except also including the gradle plugin repo

Yes

So many permutations of Google searches didn't turn that up. Maybe one that should have gone to GPT 😄

gradlePluginPortal()

is the default if you have nothing, but if you have anything you have to be explicit

Yup, I'm glad to be thinking of something correctly

ChatGPT is not helpful anyway. It is good for giving answer that look nice and correct, but not for answer that are correct. It is not for nothing that answers from ChatGPT are banned from being posted on StackOverflow for example. ChatGPT is only good for things you could actually do yourself but are too lazy (the good lazy, not the bad one) as you have to undertand what he produced and need to fix the non-sense it put in. I've yet to see a helpful programming solution by it except for the most trival things. All I've seen so far was bullshit and with methods on APIs that never existed and so on. Besidest that its data base is more than 2 years old, so ancient in computer terms, especially for a rapid evolving thing like Gradle.

Believe me, I never talk to GPT in areas I have technical competence in. I did say this was a last-ditch effort 😉

I'm following along as I'm in a very similar boat trying to fix up a multi-module project that started life as several individual projects and I've smooshed together into a monorepo. The worst part about wrong ChatGPT answers is that it answers as if it's entirely sure it is correct, where at least a person would have the sense to say they don't know.

And GPT even failed for that. I was thinking it was a sufficiently narrow-scoped question. The key word to know is "portal".. forget that, and you're not finding it

To go with that github repo for idiomatic gradle, he also has a playlist going over a ton of stuff. https://www.youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE

I just have to be honest, for some reason I find Gradle docs (and online resources) rather impenetrable. I can't think of any other software technology where I've felt that way

If you don't mind letting me know when you push your changes ndg. I'm looking over the idiomatic-gradle but it's like jumping into the deep end.

Yeah that's pushed now @BryanT 👍

I'm not entirely sure what you mean by

rootProject.name

exactly here. But yeah, if you put your plugin in group

com.example

, having

com.example.common

or

com.example.build.common

or whatever surely sounds sensible.

So my understanding is that the plugin name is being implicitly defined by

rootProject.name

, which is inferred by the name of the project directory (

common

)

The plugin id for precompiled script plugins is inferred from its name and package. If it is the same as the root project name, that's mainly convention. And if the root project name is inferred by the directory, then you do not follow best practice. 😄 Every project has to have a

settings.gradle(.kts)

and that should define the root project name to be independent from directory name.

This would suggest to me I either need to set

rootProject.name

in

settings.gradle

(I don't think the value of

rootProject.name

is best-practice expected to contain dots?), or rather: concatenate the groupId with

rootProject.name

No, previous plan did sound better. Project name should not contain dots.

Okay 🙂