This message was deleted.

You can probably declare an additional one. But I don't think you can prevent the package+name being one.

Make sense, so how can I declare the additional one?

I'd say like with any other "normal" plugin using the buidscript. Never tried though.

@Vampire Thank you for the response, and apologize for not getting back to you sooner.

The reason here is that files named differently than

build.gradle

or

build.gradle.kts

are not taken into account by Dependabot.

Then don't use such a bad tool. 😉 I would never call more than one file

build.gradle

in a multi-project build, even without any precompiled script plugins involved. Did you ever try to find the correct file in a build with 30 projects where all files are called the same? And debugging the build is virtually impossible too, as the breakpoints in that case only consider the filename and so very often stop in the wrong file visually.

Another option is to use a TOML file, but it is not yet supported in precompiled script plugins.

Well, you can use the string-y API that is officially supported and you can use my hack-around described in that issue, that practically has the same preconditions like the string-y API and is practically just a bit syntactic sugar over it. Or you could consider using a better of those imho non-sense version-update-bots. Renovate for example is much better than Dependeabot and supports many more cases. I don't know whether it supports versions in precompiled script plugins, as I don't use such tools.

Unfortunately, I don't have a possibility of using renovate instead of a dependabot but it might change in the future. What do you mean by string-y API? Could you please give some example?

Get this extension: https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/VersionCatalogsExtension.html and go on from there

I tried, but I didn't manage to make it work when publishing these plugins using Maven.

I tried, but I didn't manage to make it work when publishing these plugins using Maven.

Why not? It simply gets the catalog and the entries by strings instead of type-safe accessors. Of course it requires that the target project does have that catalog and theses entries. Exactly the same requirement as for my hack-around where you can use the accessors.

So I would appreciate it if you could provide further details regarding this response:

Examples of what? As I said there, either you need to generate some accessors from the version catalog and thus do not need to have the version catalog at the target project as you no longer use version catalogs, or you could publish the version catalog as described in the userguide and then require that the target project applies that version catalog, or provide a settings plugin that does it for the target project and require the target project to apply that settings plugin. If you decide to follow one of theses ways, feel free to ask questions if you get stuck somewhere, but I'm not going to code it for you. I'm sorry, but 🥄s are out.

Thank you for the more detailed explanation, it makes it easier to understand the possible options. I will try to check how it works in the code and if I have any questions, I will let you know.