Is this the plan for the extension andartifactId ?
Well, as I said, my recommendation is to not manipulate it, but just let the user name the project properly, so that you can just keep the default, which is artifact id is equal to the project name, which then also works better with composite builds.
But yeah, if you need it configurable, my recommendation was to make the extension interface a class again and add a function that takes the artifact id as parameter and does the configuration needed.
Regarding publishToSandbox
We have two objects here: 1) mutate group or cause the publishing to use a different group
This is not the case in what you showed above.
And it should be quite uncommon to use a different group just because you publish to a different repository.
But if this really is the case, it might again be better to set the group of the project, not on the publication.
And if it is the case, you probably also don’t want to go the route with two repositories because that would then not make too much sense.
When this task is executed the battle has lost since the configuration phase is long gone. what is the proposed approach here?
The idea was to have two repositories, one with the sandbox url, one with the non-sandbox url.
This then creates tasks for both and you can choose which to invoke.
But as I said, makes not really sense if you really also want to change the group.
It might again make sense then to have a function in your extension that sets the group on the project (not the publication) and configures the URL to the sandbox url.
The hack might lead to an issue in intellij IDEA that can be ignored, but …
The generated LibrariesForLibs extend org.gradle.api.internal.catalog.AbstractExternalDependencyFactory and this internal api seems to be invisible to IDEA and I haven’t found a way to ignore this error yet.
Cannot access class'org.gradle.api.provider.Provider'. Check your module classpath for missing or conflicting dependencies.
Cannot access 'org.gradle.api.internal.catalog.AbstractExternalDependencyFactory.SubDependencyFactory' which is a supertype of 'org.gradle.accessors.dm.LibrariesForLibs.JavaocoLibraryAccessors'. Check your module classpath for missing or conflicting dependencies.
I also tried to add the gradleApi() to the convention plugin’s classpath, but it doesn’t work either.
The gradle build via command-line or IDEA run configuration itself works. But if you don’t want to be confused by IDEA errors, you should better use the string-y API. E.g.
val libs = the<VersionCatalogsExtension>().named("libs")
dependencies {
implementation(libs.findLibrary("jacoco.agent").orElseThrow())
}
That’s very strange.
Never heard of that problem or seen it anywhere.
Also, it does not only complain about the internal class, but also about Provider from the API, which definitely should be accessible by the IDE.
Maybe try to completely delete your IDE files and reimport the project.
It seems that I had some kind of inconsistency in IntelliJ IDEAs cache. The error is gone after I did “File → Invalidate Caches…” and invalidated all caches.
