From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

that’s what GradleRunner is for - output debug/info messages as appropriate and assert on those.

`ProjectInternal` has an `evaluate()` method, that's used in some of Gradle's own tests; but I'm not sure you should rely on it for your own tests. `GradleRunner` would be much safer, albeit much heavier too.

I used `ProjectInternal#evaluate()` to test some things that happen in `afterEvaluate` but it could be fragile

Untitled.py

I see. For tests like these with GradleRunner, you'd add that logic to the build.gradle or is there a more elegant way?

I just use println in settings/build.gradle.kts and/or tasks that output info required for verification in some simple semi-structured format (like tab/pipe-separated values) with fixed prefix to filter then from stdout with more complex values just serialised with jackson in that tsv/psv.
And than anything you want for structured assertions (like assertj, assertk etc)

IIRC Vampire also recommended spock framework, it's quite handy for parameterized tests and nice human-readable assertions in test methods themselves

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, the directory not having any files in them is different from the directory not being present. No matter whether you use optional or skip when empty, if you actually configure a directory, Gradle expects the directory to be valid and present.

You need to add some logic like making that an `@Internal` property and having another property with those annotations derived from that property and then in a `map` checking whehter the directory exists and mapping to `null` if it does not exist. Something like that.

There should be examples in this Slack already regarding that.

thank you for the fast answer! I didnt have any other threads that I was messaging in , so i may be confused with someone else :sweat_smile:

~so _not_ a solution would be turning it into:~
```@get:InputFile
@get:SkipWhenEmpty
@get:Optional
@get:PathSensitive(PathSensitivity.RELATIVE)
abstract val buildDir: RegularFileProperty```
~and :~
``` if (project.buildDir.exists()) {
                buildDir.set(project.buildDir)
            }```

&gt; I didnt have any other threads that I was messaging in , so i may be confused with someone else
No, you have two threads. The second only contains "adding `@Optional` doesnt work either. it produces same error message".

&gt; ~so _not_ a solution would be turning it into:~
No, with `RegularFileProperty` you would have the same problem

alrighty I understand. keep it in one message (makes sense). and I believe I understand your response so ill try it out. thanks

for anyone who follows along:
```if (project.buildDir.exists()) {
    buildDir.set(project.buildDir)
} else {
    buildDir.set(Providers.notDefined())
}```
and make it `@Optional`
i then check in the task to see if its present

Not the best idea, `Providers` is an internal class

```buildDir.set(layout.buildDirectory.flatMap { provider { if (it.asFile.exists()) it else null } })```
if you really want to unset it if the directory does not exist.
if there is a convention defined for the property it will then also not be used.

Ah ok! I figured it was off with internal packaging name

Use a settings plugin and apply the task to the root project. This way it is impossible that another task gets registered by any project, since the plugin that applies the task cannot be applied in a build script.

Alternatively you could use a build service that performs the actual work. This would allow for multi registration of the task, but the work (with its state) is handled by the build service.

Or use a shared build service just for the information whether the task is registered already. Definitely cleaner than to cross-configure the root project with an extension that then is just there and can be seen by users.

I’m looking for a solution that is configuration-cache and build-cache compliant

Well, same answer. Use a shared build service.
Besides that it is probably unnecessary for the logger case as you can just request the same logger everywhere.

build.gradle.kts.kt

tree.txt

When I publish this I get this published to `~/.m2/repository`, I'm not really understanding the duplicate publications, one that has the implementation and one that does not.

settings.gradle.kts.kt

gradle.properties.ini

It's worth mentioning that the way it is setup this way is so that ci publish this plugin locally and then consume itself to have the configuration it needs to publish the plugin to maven.

`my-publish.my-publish.gradle.plugin` is the plugin marker artifact, so that
```plugins {
    id("my-plubish")
}```
can find it: <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers>

it is normal and expected. dependency resolution will find the actual implementation via the marker

lol, don't let your cat alone with the computer :smile:

Is there a recommended way take a dependency on a resource thats shipped as part of a plugin jar? Right now I have a task that I use to extract the resource, but it causes some weirdness in certain places, and it'd be cool to just use ArtifactViews and transformations to perform the extraction if possib.e

For anyone interested in relevant Gradle code:
-retrieval of credentials: org.gradle.api.internal.provider.CredentialsProviderFactory.PasswordCredentialsProvider
-creation of credentials: org.gradle.api.internal.provider.DefaultProviderFactory#credentials(java.lang.Class&lt;T&gt;, org.gradle.api.provider.Provider&lt;java.lang.String&gt;)
- safe credentials check: org.gradle.api.publish.maven.tasks.PublishToMavenRepository#checkCredentialSafety

(fyi, not directly related: “safe credentials” check only applies to repos on publishing tasks, not those used for dependency resolution)

<https://github.com/gradle/gradle/issues/22618>

fyi, this check is pulled from 7.6 to be revisited for more reliable methods of securing credentials.

Assuming you are building a plugin with the `kotlin-dsl` plugin then `implementation(gradleKotlinDsl())` is redundant.  As for the failure to find the dependency - that looks to be your custom artifact; assuming this is in your custom repository, you’ll want to <https://docs.gradle.org/current/userguide/declaring_repositories.html|define> that repository properly

The full build script would be helpful; the error message hints at a problem finding a plugin dependency, perhaps a <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_management|custom plugin repository> is also required.

`_build_plugin/build.gradle.kts`
```plugins {
    `java-gradle-plugin`
    `kotlin-dsl`
    kotlin("jvm") version "1.6.21"
}

project.buildDir = file("../build/build-plugin")

repositories {
    mavenCentral()
    maven("<https://maven.martmists.com/releases>")
}

dependencies {
    implementation("com.martmists.kotpack:kotpack:1.0.5")
}

gradlePlugin {
    plugins {
        create("ccos") {
            id = "com.martmists.ccos"
            // ...
        }
    }
}```
`build.gradle.kts`
```plugins {
    java
    id("com.martmists.ccos")
}```
`settings.gradle.kts`
```includeBuild("_build_plugin")```


Remove Kotlin jvm plug-in, it conflicts with Kotlin dsl.

Java-gradle-plugin is redundant and should be removed 

I'm still unable to import the relevant module with the same error

Custom repository definition is incorrect.  Need to specify url property 

```plugins {
    `kotlin-dsl`
}

project.buildDir = file("../build/build-plugin")

repositories {
    mavenCentral()
    maven {
       url = uri("<https://maven.martmists.com/releases>")
    }
}

dependencies {
    implementation("com.martmists.kotpack:kotpack:1.0.5")
}

gradlePlugin {
    plugins {
        create("ccos") {
            id = "com.martmists.ccos"
            // ...
        }
    }
}```

not the problem, but why is `buildDir` being set?  Just leave it at default of ‘build’.

settings.gradle.kts should use the newer method of including a component build for a plugin:
```pluginManagement {
    includeBuild("_build_plugin")
}```

&gt; Custom repository definition is incorrect. Need to specify url property
Is this not just a shorthand for that?

Also, now I;m getting the following:
```
e: /home/mart/.gradle/caches/modules-2/files-2.1/com.martmists.kotpack/kotpack-jvm/1.0.5/d9898d44347561e44e242cf61c29f22c228e01bf/kotpack-jvm-1.0.5.jar!/META-INF/kotpack.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.
e: /home/mart/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.7.10/bac80c520d0a9e3f3673bc2658c6ed02ef45a76a/kotlin-stdlib-common-1.7.10.jar!/META-INF/kotlin-stdlib-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.
e: /home/mart/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.7.10/1ef73fee66f45d52c67e2aca12fd945dbe0659bf/kotlin-stdlib-jdk7-1.7.10.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.
e: /home/mart/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.7.10/d70d7d2c56371f7aa18f32e984e3e2e998fe9081/kotlin-stdlib-jdk8-1.7.10.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.
e: /home/mart/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.7.10/d2abf9e77736acc4450dc4a3f707fa2c10f5099d/kotlin-stdlib-1.7.10.jar!/META-INF/kotlin-stdlib.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.```

Yep.  It now resolved your custom artifact, however that was built with Kotlin 1.7, incompatible with embedded Kotlin.  Adjust rebuild republish .

&gt; Is this not just a shorthand for that?
Yes, `maven("repo url")`  is perfectly fine

And regarding the original error, repositories are not transitive.
While *building* the plugin you have the repository where to find the dependency defined.
But while *applying* the plugin you have to define the respository as plugin repository in `pluginManagement` of the settings script.
You can see in your error message that it was only searched in the Gradle Plugin repository which is used as default if no repositories are defined.

Generally that would be passed into the build service method.

Ok. I figured it would be, just wanted to know if there was a better way, especiall without having to go cross project.

There is this thread: <https://github.com/gradle/gradle/issues/1686>

<https://status.gradle.com/|https://status.gradle.com/>

basically jcenter is having issues again, gpp historically forwarded to jcenter, changing that will break some existing builds.

according to the status page, they're now (temporarily?) forwarding to maven central, as there will be fewer builds broken than redirecting to jcenter at this time, but it's inevitable that there will continue to be some breakage

anyone know why Gradle can’t just lift everything from JCenter that is needed by the plugins and host those artifacts themselves?

1. Why you don’t apply the version and group to all projects with the convention instead of getting it from the root one?
2. I think you can get the version catalog extension from any project.
3. I think there is an issue that it is reconsidering improving `allprojects` to be compatible with project isolation (I think that the incompatibility shouldn’t be `allprojects` itself, instead only if a project is using other project, as applying a config in a `forEach` like function doesn’t implies all projects depend among them).

For #1 - a lot of projects  have many modules, each of which applies a base convention plugin (that pulls the group etc from the root project, among many other common conventions); these projects don’t necessarily have their own convention plugin, nor do they need one (creating one just for these would be unfortunate)
For #2 - would you have an example/reference of accessing version catalog from anywhere?
#3 - looks like using `beforeProject` (available on the gradle object in an initscript) solves this.

1. Probably solving the issue about `allprojects` breaking project isolation should allow you to apply convention plugins to all projects easily. Another think I have thought about it is that project isolation should work like Gradle tasks, if a project depends on another, it can wait until the other is configured, so in this example, all projects should wait until root is configured, and then all rest projects configured in parallel, instead of crashing.
2. Nothing special, in Hubdle I have a mechanism to autogenerate dependencies but I allow the consumer to replace the version if the artifact is declared in a version catalog. `val catalogExtension: VersionCatalogsExtension? = project.extensions.findByType()`.
3. Nice to know :thinking_face: 

thanks - will give #2 a try.  For the time being, solving #1 with a shared build service.

I have curious about your solution, it will work because root is configured always the first, but what would happen if that was not a fact and any project could be configured before the root one :thinking_face:

yep.  :boom: .  have exceptions that will be thrown if that happens.  A bit fragile, though liveable (and encapsulated) until a better solution comes along.

<@U02S31Y7J2K>, would you please share your use cases on <https://github.com/gradle/gradle/issues/22514> ?

Thanks <@UABCKNV3K>, added them <https://github.com/gradle/gradle/issues/22514#issuecomment-1308855067|here>.

```@Input
public val packageJson: RegularFileProperty =
    objects.fileProperty().convention(directory.map { it.file("package.json") })```

```@Input
public val packageJson: RegularFileProperty =
    objects.fileProperty().convention(directory.file("package.json"))```

I should have checked it was compiling instead of looking the signatures :upside_down_face:

Most examples I've seen check the extension values in `afterEvaluate` .

Elaborating on my usecase , There are plugins `A` and `B` with extensions `Aext`  and `Bext` .
I want to be able to configure `Bext` from `A` using the values configured in `Aext` .
Do let me know if this is a bad practice and/or a better way to do this :slightly_smiling_face:

I could configure `B` from the task action of `A`. However that would require access to the project  instance which would not be Configuration Cache compatible.

In `Bext` only I'd rather configure it's properties with convention referring to `Aext` values.

From <https://github.com/gradle/gradle/blob/master/subprojects/kotlin-dsl/src/main/kotlin/org/gradle/kotlin/dsl/ConventionExtensions.kt#L36|ConventionExtensions.kt>
&gt; The concept of conventions is deprecated. Use extensions instead.
Are you referring to the same conventions or a different concept?

I refer to the conventions mechanism of lazy configuration when defining default values for properties:
<https://docs.gradle.org/current/userguide/lazy_configuration.html#applying_conventions>

Ah okay. So I think, I could do this by using providers too ? Something like `Bext.fooValue.set(Aext.fooValue)`

This makes sense :+1:  , however `B` in this case is `maven-publish` which does not seem to use providers for all its properties.

```Bext.myProperty.convention(Aext.otherProperty)```

Do not have properties in Aext, but functions that do the Bext configuration when the method is called.

If you only want to support usage in Kotlin DSL, you can also create an extension function that looks like the extension accessor Gradle generates instead of registering the extension. That would allow you to do your logic at the end of that extension function. But that would then also be able to be called if the plugin is only on the classpath but not applied.

Another option would be that your extension has only one function with an `Action` argument which configures another class having the actual properties, then that function can trigger the post-configuration action. That would then look like
```aext {
    config {
        foo.set("bar")
    }
}```

That's a lot more ways than I expected possible . I will try these out and get back. Thank you once again!

Because you either set `executable` and `args` OR `commandLine`

By setting `commandLine` you are overwriting `executable` with the first element of `commandLine`

And even then, you need to do something like `zsh -c "diff &lt;(a) &lt;(b)"` or similar, because it is a zsh feature to do this command substitution

that, and `&lt;()` process substitution is handled by the shell, not by the OS. you are bypassing the shell with that `commandLine`

yeah, what Björn says. `&lt;()` is also a feature in Bash at least

oh interesting so if I dont set `executable`, then I received originally
```Caused by: java.lang.IllegalStateException: execCommand == null!```
thats why I thought i had to set it. but this is v helpful thanks. I wanted my tasks to register but skip actual command line commands if i had a flag set for say, `outputOnly`

if you really need to calculate arguments lazily, you can register a <https://docs.gradle.org/current/javadoc/org/gradle/process/CommandLineArgumentProvider.html|CommandLineArgumentProvider> I think

Oh I figure it out… I need to add the integrationTest source set to the gradlePlugin  dsl config to make the auto-injection work.
```gradlePlugin {
    ...
    testSourceSets.add(project.sourceSets.getByName("integrationTest"))
}```


If you did properly publish, you published multiple artifacts, the main code artifact and additionally the marker artifacts that resolve id to actual code artifact. So if you properly published, you can just use
```plugins {
    id("my.conventions.helloWorld") version "1.0-SNAPSHOT"
}```
with having the repository where you published it to defined as plugin repository in the settings script.

i thought gradle plugin reposi were special

No, it is just another Maven repository with a custom search web ui

They are simply another artifact with coordinates `&lt;plugin id&gt;:&lt;plugin id&gt;.gradle.plugin:&lt;plugin version&gt;` that has no jar. It has a normal metadata file according to the repository you publish to, so a pom for a Maven repo, an ivy.xml for an Ivy repo and usually additionally the module file like usual.

do i need to use another target? i have the maven-publish and groovy-gradle-plugin configured in the project

I think that should have published it properly.
Maybe you did not set up the build properly then.

Btw. always using `clean` is non-sense that was just necessary with Maven as it never works properly without it

If it is necessary with a Gradle build, there is a bug in the build

You just waste time by redoing things that are already up-to-date otherwise

that's just my bad habit from using mvn for so many years

i can see in the jar with all my gradle convention  scripts are there. note that my convention plugins were written as gradle files, not groovy or java

do i need to create the files in the META-INF/gradle-plugins dir?

oh, i think i need to add these <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers>

&gt; note that my convention plugins were written as gradle files, not groovy or java
That is a so-called precompiled script plugin, that's fine.
The `groovy-gradle-plugin` should take care of them being compiled into proper binary plugins and also set up the publishing and so on.
&gt; do i need to create the files in the META-INF/gradle-plugins dir?
You should never do that, but at most configure the plugin in the build script and the files for there are generated automatically.
In the case of precompiled script plugins, you don't even need to configure in the build script as the `groovy-gradle-plugin` should do it for you.

They also add the marker artifacts automatically.

I think we are at a point where I cannot guess anymore without you providing an MCVE of your problem

adding the gradlePlugins block uploaded the various pom files to the repo, so im making progress!

Shouldn't be necessary I think. :confused:

i got it working! thank you so much <@URQ797WRW>

sorry for bothering you again, i have a plugin that adds repositories to the root project. I addded it to thte plugin section (with apply false), then apply plugin blah. The project is saying no repositories are defined. Is it possible to use a conventions plugin to add repositories?

Why do you use `apply false` if you want to apply it? Does not sound helpful.
Yes, a plugin can define repositories, though I greatly prefer to define repositories centrally in the settings script.
Why you get that error is hard to guess without seeing the code.

i have a separate section where a use `apply plugin &lt;blah&gt;`

i'll keep looking and won't bother you! Thanks again for your help, i've come a long way over the last few hours thanks to you

You should actually not use `apply plugin &lt;blah&gt;`, that is legacy and shouldn't be used. You should apply using the `plugins { ... }` block

I had to reach once the other's project gradle.properties file and I couldn't find the nice solution. I finished up with picking the property I wanted with script:

```GRADLE_PROPERTIES_FILE=../../gradle.properties

function getProperty {
    PROP_KEY=$1
    PROP_VALUE=`cat $GRADLE_PROPERTIES_FILE | grep "$PROP_KEY" | cut -d'=' -f2`
    echo $PROP_VALUE
}
testDistributionEnabled=$(getProperty "com.testDistributionEnabled")
echo "Test Distribution Gradle property enabled: $testDistributionEnabled"```

im using the file in ~/.gradle . Turns out gradle maps it into the build so all i had to do was use `project.property ('foo' )`

You can even just use `foo` as you obviously use Groovy DSL

If it is valid that it is not set, then `findProperty('foo')`

obviously  the project has its own metaclass?

Just btw. If you are looking for some local properties adjustments we are using <https://github.com/stevesaliman/gradle-properties-plugin> you just keep gradle-local.properties file in your repo (that is excluded in .gitignore) and that overrides the values from gradle.properties :wink:

Which completely destroys task configuration avoidance and configuration cache compatibility, so better think twice before you use it. :wink:

We plan starting use the configuration cache soon, should we drop this plugin? Any counterpart for it?

Unless some things are fixed, I'd recommend that, yes.
And even if those things that are fixable are fixed, you also have to take care that any spot using the new `providers.gradleProperty`, which can be used in any plugin you apply, will not get the values from the local properties, as this provider only checks the actual Gradle properties and not the "extra" properties that are used by the plugin to overwrite the values with values from the local file. That is a point that cannot be fixed yet as there is no API to programmatically set a Gradle property. As long as the property is accessed the other way (e. g. `project.findProperty(...)` and friends) the extra properties are searched first and it works, but there is no guarantee that it works for all properties some plugin might read using the provider.

And no, I know of no alternative, and especially the last part is not fixable right now.

if <https://github.com/gradle/gradle/issues/9164> were implemented, you'd be able to
```eachFile {
    lastModified = MY_CONSTANT_TIME
}```
but for now there's no way aside from writing your own archive tasks

I remember this: <https://github.com/gradle/gradle/issues/14819#issuecomment-976032392>, but it’s a custom solution.

curiously, it seems that `Tar` and `Zip` use different fixed timestamps
<https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/TarCopyAction.java#L45>
<https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L56>

There is some limit how zip stores dates, so that is why zip has 1980.

*sigh*. I see Max had the same issue years ago ..

<https://salsa.debian.org/reproducible-builds/strip-nondeterminism> does even more than just zip timestamps: fixing manifest timestamps in JARs, for example

I really would like to avoid writing my own copy actions :sweat:

maybe you could clone that project and add
```tasks.jar {
    isReproducibleFileOrder = true
    doLast {
        project.exec {
            executable("perl")
            args("strip-nondeterminism", archiveFile.get().asFile)
        }
    }
}```
to your task? (untested)

ZOMG, no thanks. That’s even worse. As now every build node has external dependencies to perl _and_ the strip-determinism project

<https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:finalizer_tasks>

so i can expose a new task with my own custom Task class, but can i have something that won't need any changes to the build script?

You said "in a plugin", so what's your point? *confused*

sorry i meant in a way where the build script didn't have to be changed

You don't have to change the build script if the plugin registers this task and sets it as finalizer task

i was just going by this page which required the script to still register it i guess <https://docs.gradle.org/current/userguide/custom_tasks.html#sec:custom_tasks_standalone_project>

Everything a build script can do a plugin can do too

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

i'll use a util function like this in tests all the time.
```fun Any.getResourceAsStream(path: String): InputStream {
  val loader = requireNotNull(this.javaClass.classLoader) {
    "Unsupported with current classLoader impl, see Class.getClassLoader() doc for more info."
  }

  return requireNotNull(loader.getResourceAsStream(path)) {
    "Resource with the path `$path` not found."
  }
}```

thanks, that’s a good starting point; looking to see if there’s a clean way to tie that into a configuration, without writing all the glue to read into temp files etc.

Maybe with `resources.text.fromUri("...").asFile()`?

Or with an artifact transform that extracts the json file/s and then adding a dependency on the plugin artifact with that transform applied.

input stream straight into your json parser is how I usually go about it

He did not say he wants to parse them :wink:

correct, they need to be dependencies in a configuration.  thanks <@URQ797WRW> will give those a try.

artifact transform sounds like a good fit. would give you caching of the work for basically free too I believe

Artifact transform is probably the cleaner solution but with more ceremony

likely yep.  working through a POC for this, but it’s fragile to match up the right module etc.
``` buildscript.configurations.getByName("classpath").resolvedConfiguration.resolvedArtifacts.map {
        it.moduleVersion
    }```

with some filtering and zipTree stuff could get there, but not cleanly…

It is your plugin, just put the version and coordinates into it when you build it, then you can simply use it.

fyi, this is working.
```val thisPluginArtifact =
    buildscript.configurations.getByName("classpath").resolvedConfiguration.resolvedArtifacts.first {
        it.moduleVersion.id.name == "myName" &amp;&amp; it.moduleVersion.id.group == "myGroup"
    }
val jsonFileTree = zipTree(thisPluginArtifact.file).matching {
    include("some-dir/**/*.json")
}

val myConfiguration by configurations
dependencies {
    myConfiguration(files(jsonFileTree))
}```

My first attempts resulted in messages saying `Publication only contains dependencies and/or constraints without a version`. What's even stranger is even after i commented out the plugin and put in my old publishing gradle config, I still get the message!

i dont know how to fix the build now. I cleared all gradle caches, restarted the daemons, restarted the entire machine, still get the error when trying to publish

Are you setting the project version or the version in the publishing config?

```group = …
version = …```

i never had to in the gradle file, both of those are in the gradle.properties file

in another project where im trying to use the plugin, it's complaining because the publish plugin is running before the jars are created

If applying a plugin too early is a problem, it has a bug. Plugins should not depend on application order and I doubt the built-in ones have that problem. But hard to say without the exact error and maybe some code.

plugin source is here <https://gist.github.com/Impakt/88f2a5a133cea5753571f88bd638bb0b>

all i want it to do is publish as per normal (with sources at some point), but choose the repo based on whether the version ends with `SNAPSHOT` or not

gives me an error on the generateMetadataFileForMavenJavaPublication task, using 7.5.1

Looking at the code from SO you linked, I think there are basically two things missing:

1. React to the application of the "java" plugin. Otherwise the _java_ component is not available:
```plugins.withId("java", p -&gt; {
  // publishing config goes in here...
});```
Alternatively, and probably cleaner: also do `project.getPluginManager().apply(JavaPlugin.class)` in the top as you'll use your custom plugin only in Java projects anyway.

2. In the `publications.create` part *only* use the component (don't use _artifact_, do not refer to a task directly)
```publications.create("mavenJava", MavenPublication.class, mavenJava -&gt; {
  from(project.getComponents().getByName("java"));
});```


Tried all that, still getting the same issue. I'm trying to use this on a multi module project. If i apply it on the root (which has no code), i get a file not found error (t's trying to find the jar on the root project which will never exist). If i don't apply it to the root then it says task 'publish' not found in root project

if i only add the publications and repositories to the projects that have a `src/main/java` dir (meaning the root project has the plugin applied but no pulications or repos defined), the build succeeds in a few seconds (in other words, succeeds but actually does nothing)

changed to `java-library` instead of `java`, same thing

Maybe you should provide an MCVE showing your problem, especially if you apply it to the projects where it belongs instead of the root project and it does not behave like expected.

i managed to fix this by swapping out the old plugin class to a gradle script, and it works perfectly now

Currently I have a task which is extending a `NpmTask`  from a third party library.

But instead of extending that task, I would like to use, based on a property, npm, npx or yarn.

So I would like somehow "inject" those three kinds of task and my task should choose which implementation to use based on the property.

Ideally the other plugin would provide something like Gradle's `ExecOperations` around which those tasks would just be thin wrappers; so you wouldn't directly use the tasks themselves from your custom task.
It looks like <https://github.com/node-gradle/gradle-node-plugin> internally does just that (and by internally I mean the tasks are implemented that way, but the API used there is not `internal` so I would assume it's public and you can safely use it; ask the author for confirmation)

Basically we use a 3rd party plugin whose service is a bit flaky but who don’t want to modify their gradle plugin to handle transient errors.

Iirc, no, if the task does not provide a way to not fail on error like the test task does, it is not possible I think. You can use `--continue` to still run tasks not depending on the failed task.

I am not sure if this works in all scenarios, but you can dynamically change the actions of a task. So you can remove the task action, wrap it in a new more lenient action (e.g. catching the exception). For example:

```tasks.someTask {
    val action = taskActions[0]
    taskActions.clear()
    doLast {
        try {
            action.execute(this)
        } catch (e: RuntimeException) {
            println("[WARNING] " + e.message)
        }
    }
}```

Oh, nice.
I was aware that you can clean the task actions and replace it with something else, but not that you can also delegate to the original actions.

<@U023HSZL88M> Oh neat! I had read in the docs that tasks were really just a collection of actions themselves, but wasn’t aware you could modify them directly like that. Feels evil :smiling_imp:

Actually you should probably use `actions`, not `taskActions`. The former is part of public API, the latter is only part of the internal superclass.

I would hope for an API on `getInputs()`, but doesn't look like it provides me with a way to ignore a particular one

not to my knowledge, no.  the general pattern i use is for tasks to define their specific inputs (not relying on external configuration), with the plugin/script then providing those inputs (often from an extension, for example).

unfortunate.  if the task is a thin wrapper over some accessible logic, you could create a new implementation of it and disable the other one (or perhaps replace it’s actions).

If the property is not a Gradle `Property` you could set a dummy value and update the value using `doFirst {}`. You would basically “jump” over the up-to-date checking. Not something I would recommend but it worked for me in a couple of scenario.

It won’t work for Gradle `Property` because they are finalized after up-to-date checking so you can’t change them in `doFirst {}`.

(well starting at some version of Gradle)

^^^ the goal is to have the task up-to-date, to avoid execution, incl. doFirst.

given that this is an extension shared by more than one task, I don't think mutating would be a good idea, but I think I have found a way, let me check...

nope, doesn't seem to work... what I tried:
&gt; task.getInputs().property("options.runtimeArgs", ZERO_ARGS)

Is the extension set onto the task? If that is the case, just reinstantiate another one and set that new one that have being mutated.

unfortunately it didn't work: <https://scans.gradle.com/s/pwsajnwn74swo/timeline?details=bv5s2wr7irnke&amp;page=2>

I'm not sure I can _independently_ set a new extension reliably without `afterEvaluate` :confused:

If you want it to be updated at the last possible moment, do the mutation in `dependsOn`. :laughing:

What you can do is to mark the extension with `@Internal` and then add a second, optional property of the same type annotated with `@Nested`. The second property then would return the extension when you care about the inputs and would be absent if you don’t.

And how would he do that in a 3rd party task that he cannot change?

Probably by creating a subclass of the task and there "fixing" the annotations, or monkey-patching the task class using `buildSrc`.

perhaps, though the issue isn’t about the task, it’s about the task depending on the extension as input, which is an overly broad dependency (extension includes things not relevant to the task at hand).

There’s also the `TaskContainer#replace` that can be an alternative to monkey-patching.

Wasn't `replace` deprecated because it could already be used in `dependsOn` or property wirings and so on and thus not work cleanly?

seem to recall something about that, though it isn’t deprecated in current code.

If I remember correctly, `replace` is deprecated if the task is realized.

&gt; perhaps, though the issue isn’t about the task, it’s about the task depending on the extension as input, which is an overly broad dependency (extension includes things not relevant to the task at hand).
Yes, but at the same time it's difficult to get rid of this, I'm already multi-repo :slightly_smiling_face: And `replace` isn't an option.

I will go with "cannot fix" right now, and will update the "faulty" plugin with what Stefan suggested. It's going to take longer because those have different lifecycles, but life isn't always as easy as we want it.

perhaps it’s worth trying monkey-patching as <@URQ797WRW> suggested.  Create a version of the class in buildSrc (to override existing version), maintain API compatibility (expose same properties, make the extension as @Internal).  Then have plugin set just the input properties needed for this task.

<@UA8P8BBEG> so here's the task: <https://github.com/graalvm/native-build-tools/blob/ed7021b9a0bce55a3b55ccc2dcd41c603f94c25e/native-gradle-plugin/src/main/java/org/graalvm/buildtools/gradle/tasks/BuildNativeImageTask.java#L92>
My question would then become: if I make the extension property internal, how can I guarantee that I don't forget to create "delegated properties" for each of the new members of the extension, on the task?