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

Gradle Community

I doubt there are any "good examples", because whenever you need a "complete set", you have problems as you never know whether your some pluign applied after yours does more work or whether the build script does more work after your plugin was applied, or whether the evil `afterEvaluate` block of a build script or another plugin is executed after an `afterEvaluate` you register and does add there.

A complete picture is generally just available after configuration phase has finished, so you cannot do additional configuration based on it.

Maybe if you elaborate on your use-case someone can suggest a different approach of how to achieve what you need.

Right, I get that.  I was looking for something like `SourceSetContainer#all`

The overall use cases is to apply a task for bytecode enhancement.  If a Java SDS is available, apply enhancement to it. If a Kotlin SDS is available, ...

`project.getPlugins().al( ... )` but that feels icky for some reason

probaby because it is a bit open-ended... its any jvm targetting lang

Maybe an alternative way to look at this is based on compilation tasks (AbstractCompile)

Can't you just use the `classesDirs` or `output` of the `SourceSet` or similar and not care about actual `SourceDirectorySet`s?

Its the same problem no?  Things after me could add new ones

You said you have a task for bytecode enhancement.
So when the task executes, there should not be anything added anymore

It ties in with a question I was asking yesterday about bytecode enhancement and up-to-date.  if I do the enhancement in place it messes up up-to-date checks.  So I had the thought to offer the user an option to enhance in place or to a distinct directory.  In that second case, I was worried about mimicing the classes dir structure.  But maybe I am just overthinking this

I could just let the user specify the SDSs to process

I had considered that approach using FileCollection, but nothing says FileCollection has to be directories

Why should you care to maintain the classes dir structure?
Gradle produces the class files in different directories, as tasks should not have overlapping outputs.
But if you have one task that takes the classes of the other tasks and does a bytecode enhancement on them,
I'd say it is perfectly fine to have them land in one output directory per source set.

&gt;  I'd say it is perfectly fine to have them land in one output directory per source set.
That's probably reasonable as well

As I said, I'm not sure to whom you are trying to be nice, and what benefit they have. :slightly_smiling_face:
That it lands in different directories is a pure technical necessity to not have overlapping output directories.
In former days, long ago, Groovy and Java compile tasks compiled into the same output directory.
It was just found to be problematic with things like up-to-date checks and task output caching, so it was split to have dedicated output directories per task.

Sure, I get that.  Like I said, I planned on allowing the choice between in-place enhancement and enhancing to a separate dir.  I was just trying to have the same logic to write out the enhanced classes based on a base dir

No real technical reason other than being a lazy programmer :wink:

Anyway, I am playing around compile.doLast (based on the other discussion) to see if that helps with the up-to-date stuff and just always do in-place.  That would by far be the best outcome

up-to-date should work fine with that.
Incremental might become a problem maybe, not sure.

incremental as in `@Incremental?` Yeah that would be a shame, but pick poison it sounds like

Anyway, thanks for the thoughts as always.

Always a pleasure :slightly_smiling_face:

TestKit is the way most plugin integration testing is done

This is a discussion about plugin development.  Hence I assume that is what you mean

I'm expanding the template
```val projectDir = File("build/functionalTest")
        projectDir.mkdirs()
        projectDir.resolve("settings.gradle.kts").writeText("..")
        projectDir.resolve("build.gradle.kts").writeText("..")
        // Run the build
        val runner = GradleRunner.create()
        runner.forwardOutput()
        runner.withPluginClasspath()
        runner.withArguments("generateTerraform")
        runner.withProjectDir(projectDir)
        val result = runner.build()```

Dunno, breakpoints always JustWork for me

You must have something like `testImplementation gradleTestKit()`

unless the plugin plugin applies it automatically, but i do not believe so

anyway, sorru i cannot help as breakpoints always just work for me.  though i use Java based testing

unfortunately `testImplementation(gradleTestKit())` didn't work
just to be double sure, you simply execute the test via the Idea gui (column on top left) choosing the debug option and that is?

Yes.  In fact I can even set breakpoints in the build script

Dunno, like I said you use a different approach for testng (Groovy it seems) whereas I use Java.  And I assume you then use Groovy for implementing the plugin (which is not the recommendation as far as I understood).  So that may all factor into it

I'll step away from trying to help as you have a very different set up

See <https://docs.gradle.org/current/userguide/test_kit.html#sub:test-kit-debug>

awesome, `withDebug(true)` works as a charm, thanks!

support for TOML as a configuration language

I guess that Alan is for "Turing complete"

<https://twitter.com/lexi_lambda/status/1533127548577652737>

Isn't the whole point of convention to define a value to be used if one is not set?

It may be that `add()` is eagerly evaluating that provider.  See if `addLater` works.

I don't see addLater.  There is addProvider, but that gave me the same

```		project.getDependencies().addProvider(
				"implementation",
				ormDsl.getHibernateVersionProperty().map( (ormVersion) -&gt; Character.isDigit( ormVersion.charAt( 0 ) )
						? "org.hibernate.orm:hibernate-core:" + ormVersion
						: null
				)
		);```

maybe because I return the null?  I saw that onine, but maybe that just does not work...

Really I'd prefer to invert that, bu not sure how to in a deferred fashion

`addLater` is on the configuration:
```implenentation.dependencies.addLater```
…unsure how that relates to addProvider.
Yea, have seen the `null` as well

You mean this right? `project.getConfigurations().getByName( "implementation" ).addLater()`

odd.  using it:
```        // lazy initialize dependencies from packaging extension
        packagingScripts.dependencies.addLater(packaging.packagingScript.map { dependencies.create("${it}@zip") })```

Try with a `.get()`:
```project.getConfigurations().getByName( "implementation" ).get().addLater()```

getByName returns a Configuration though, not a Provider

ah yea it’s `named` that has a provider.  ok, that looks like it should work.  addLater is documented on DomainObjectCollection as being there since 4.8.  Not seeing any kotlin magic in there.  This is the full context:
```        val packagingScripts: Configuration by configurations.creating

        // lazy initialize dependencies from packaging extension
        packagingScripts.dependencies.addLater(packaging.packagingScript.map { dependencies.create("${it}@zip") })```

ah - need to reference dependencies:
```project.getConfigurations().getByName( "implementation" ).dependencies.addLater()```

```		project.getConfigurations().getByName( "implementation" ).getDependencies().addLater(
				ormDsl.getHibernateVersionProperty().map( (ormVersion) -&gt; Character.isDigit( ormVersion.charAt( 0 ) )
						? project.getDependencies().create( "org.hibernate.orm:hibernate-core:" + ormVersion )
						: null
				)
		);```
Same :disappointed:

huh.  seeing the same thing:
```val prop = objects.property&lt;String&gt;()
prop.convention("N/A")

// this fails with expected error: Supplied String module notation 'N/A' is invalid. Example notations: 'org.gradle:gradle-core:2.2', 'org.mockito:mockito-core:1.9.5:javadoc'.
// dependencies.addProvider("implementation", prop.map { it })

// this fails with: Cannot query the value of this provider because it has no value available.
dependencies.addProvider("implementation", prop.map { null })```
Has seen somewhere using `null` to indicate a no-op.

i think the convention part is working - that is passed into the map closure, which then returns `null` for `N/A` input.  It that null on the derived provider that is problematic…

Perhaps.  Like I said, I would much prefer to invert tht, but afaik that is not possible

is the goal to not add the dependency if no version (or an invalid version) is specified?

this <https://melix.github.io/blog/2022/03/gradle-conditional-dependencies.html|reference> shows conditionally adding deps.  perhaps what you’ve already seen.

the plugin is published along with the rest of Hibernate.  we generally expect (and only really support) the same versions be used for performing the bytecode enhancement and consuming the enhanced classes

cross version bytecode enhancement suport gets to be way too tricky for what I want to do :wink:

yea, definitely not that.  this:
```implementation micronautExtension.runtime.map { r -&gt;
        switch(r) {
            case 'netty':                                                   (1)
                return "io.netty:netty-buffer:4.1.75.Final"
            case 'tomcat':
                return "org.apache.tomcat.embed:tomcat-embed-core:10.0.18"  (2)
            default:
                return null                                                 (3)
        }
    }```
…but it doesn’t seem to work, trying it now.

but no, this is not the one i saw.  i'll read through it. thanks!

he uses the Groovy DSL to accomplish this.  i wonder if that comes in to play here

perhaps.  not having any luck with Kotlin DSL, though it should be equivalent in this case:
```dependencies {

    // fails with: Cannot query the value of this provider because it has no value available.
    implementation( prop.map {
        null
    })
}```

not quite as user friendly, but maybe i'll just drop this for now and focre the user to add the dependency manuallyand keep the versions in sync

btw, is there any real different between `#set` and `#value`here?

no.  from what I’ve seen, #value was added more recently to help clarify setting the value vs setting a provider.

yea.  looks like the only diff is that `value` allows chaining.  I’ve used extension functions to provide this for clarity:
prop.value = something // assignment of a value
prop.from(otherProp) // from a provider of some sort

ah, you're right they do define diff return types

having developed chaining apis... hate them :laughing:

they get super fugly to implement when you introduce inheritance

Actually I guess that was the resource was the one I saw since I left a reply :smile:

couldn’t get a single dependency to be conditionally added via `null` - but you can use `addAllLater` to add a list of deps (empty list for no deps).
```configurations.implementation.get().dependencies.addAllLater(prop.map {
    if( it == "N/Addd") { listOf(dependencies.create("io.foo:default-dep:1.2.3")) }
    else { emptyList() }
})```

Thanks <@U02S31Y7J2K> I think I am going to drop this though and either :

1. drop this setting and force the user to add the dependency
2. never use null and always use the version of the plugin or an explicitly set version

<@U02S31Y7J2K> out of (yes even more) curiosity, what contributes `#listOf` here?

Also, how about `#emptyList`?  Gradle seems to expect certain List impls.  `Collections#emptyList` / `Collections#singletonLit` e.g. give me

```   &gt; class org.gradle.api.internal.provider.TransformBackedProvider cannot be cast to class org.gradle.api.internal.provider.CollectionProviderInternal (org.gradle.api.internal.provider.TransformBackedProvider and org.gradle.api.internal.provider.CollectionProviderInternal are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @29e235a1)```

ah.  listOf() is Kotlin syntax.  iirc for Groovy it would be a list literal `["a", "b"]`.  emptyList() is also Kotlin, would be `[]` iirc.

ah.  odd that Collections.emptyList() doesn’t work.  all it wants is something that is `Iterable`.

that cast exception looks like perhaps map() isn’t returning a Provider&lt;Iterable&gt; but a Provider&lt;Something&gt; that ends up going into addAllLater.

Ah, yes, ofc.  silly mistake.  It is returning `Provider&lt;List&lt;?&gt;&gt;`.  It does not know because of the emptyList

s/b able to do `Collections.&lt;String&gt;emptyList()` for get the right type.

actually, if i set a var you don't even need that

anyway, still fails.  it is for sure the map call and attempting to use that here

let me check, had some challenges with that before…

hmmm.  this (Kotlin) syntax works:
```configurations.implementation.get().dependencies.addAllLater(prop.map {
    if( it == "N/Addd") { listOf(dependencies.create("io.foo:default-dep:1.2.3")) }
    else { emptyList() }
})```

:shrug::skin-tone-3: not the first time i'd have seen diffs in groovy v java v kotlin

what does your code calling map()  look like?

this is just one of those cases where Gradle is not going to make sense :smile:  I'm back to this working now -

```		project.getDependencies().add(
				"implementation",
				ormDsl.getUseSameVersion().map( (use) -&gt; use
						? "org.hibernate.orm:hibernate-core:" + HibernateVersion.version
						: null
				)
		);```

I'm going to push soon, i cann link it after

that… works? wasn’t able to get a provider that returns null to work.

even when it hits the false path and returns null?

i now have a `Property&lt;Boolean` just indicating whether the users wants tis

so ether i'll inject this, or they can set up the dep manually in their build

Can't imagine why `Property&lt;String&gt;` v. `Property&lt;Boolean&gt;` would make any difference though

But like I said, I think I am missing some nuance to convention

huh. still not getting that work, looks like the Provider layer doesn’t accept null return values.
```val prop = objects.property&lt;Boolean&gt;()
prop.convention(false)

// fails with: Cannot query the value of this provider because it has no value available.
dependencies.add("implementation", prop.map { null })```
…at least in this repro (Kotlin DSL, Gradle 7.4.2).

There is not much docs about it unfortunately: <https://github.com/gradle/gradle/issues/20833|https://github.com/gradle/gradle/issues/20833>

Do you maybe have an MCVE with your non-working state?

I do not, but basically most of the issues revole around it not being able to instantiate custom managed types in a same way as NamedDomainObjectContainer. So for now instead of registering bindings, I register factories that just call into ObjectFactory::newInstance

Not sure if the two containers are event expected to function in the same way

For me `registerBinding(Foo::class, Foo::class)` and `registerBinding(Bar::class, Bar::class)` was enough to make the container work with `Foo` and `Bar`

Does your element types implement / extend `Named`?

They do and because of that I kept getting "Cannot have abstract property Named.getName()" errors :smile:

Also it wouldn't inject my managed properties complaining about missing ObjectFactory in services

Is your project by any chance open source?
Or can you extract the relevant part to an MCVE?
Would really be much easier :slightly_smiling_face:

It's basically this <https://github.com/JetBrains/kotlin/pull/4853>
But as I've said - I just gave up and went factories route

Appreciate you trying to help nonetheless

Do you maybe still have the non-working / half-working state where you tried with EPDOC and could push it to some branch?
I'd have a quick look and see where the problem might be.

At least "Local History" should have it :slightly_smiling_face:

Just about to push it in, apologies, I'll send you a direct link once that's done

<https://github.com/JetBrains/kotlin/pull/4853/files#diff-0e8c85272d583bd09b82dfd8088e649bd4faad783cc662b58a4cde8c85e46312R31>

I basically have this which finally worked:
```interface Base : Named {
    val url: Property&lt;String&gt;
}
interface Foo : Base {
    @get:Inject
    val objects: ObjectFactory

    val children: DomainObjectSet&lt;FooChild&gt;

    fun child(nick: String) {
        children.add(createChild(nick))
    }

    private fun createChild(nick: String): FooChild {
        return objects.newInstance&lt;FooChild&gt;().also { child -&gt;
            child.nick.set(nick)
        }
    }
}
interface FooChild {
    val nick: Property&lt;String&gt;
}
abstract class MyExtension {
    @get:Inject
    abstract val objects: ObjectFactory

    val baz = objects.polymorphicDomainObjectContainer(Base::class).apply {
        registerBinding(Foo::class, Foo::class)
    }
}```


Might be an issue with me using abstract class instead then

I hope it shouldn't, I just prefer interface where possible to save boilerplate

No, I replaced all three interfaces to be abstract classes and made the four properties abstract and it still works fine

Yay, there are some really long file names in that code base :disappointed:
My work-windows does not really like those too much.

And what do I call to reproduce the error with that state checked out?

Ok, so first, you need to change the factories to type bindings <https://github.com/JetBrains/kotlin/pull/4853/files#diff-0e8c85272d583bd09b82dfd8088e649bd4faad783cc662b58a4cde8c85e46312R38|here>. Then you can run
```./gradlew :kotlin-gradle-plugin-integration-tests:kgpJsTests --tests "org.jetbrains.kotlin.gradle.JsIrConfigurationCacheIT.testBrowserDistribution"```

Note that you'll need JDKs 6, 7, 8 and 9+ installed for the project to configure (I used sdkman and gradle toolchains detected them just fine)

Oh and feel free to go watch a movie or something, the project can take up to an hour for first time configuration :D

&gt; Hah got curious, didn't you? :D
I don't need to become, I always am. :-D
&gt; Ok, so first, you need to change the factories to type bindings <https://github.com/JetBrains/kotlin/pull/4853/files#diff-0e8c85272d583bd09b82dfd8088e649bd4faad783cc662b58a4cde8c85e46312R38|here>
Ah, I see, I misunderstood actually.
I thought you didn't get it managed even with `registerFactory` and went some other route, that state being the broken one.
That it works with `ObjectFactory#newInstance` but not with the binding is imho even stranger.
&gt; Note that you'll need JDKs 6, 7, 8 and 9+ installed for the project to configure (I used sdkman and gradle toolchains detected them just fine)
I happen to have these already. :slightly_smiling_face: 6, 7, 8, 11, 16
I'm more concerned that build will eat up my disk space actually. :smile:
&gt; Oh and feel free to go watch a movie or something, the project can take up to an hour for first time configuration :D
Actually, I went to sleep after opening the project in IntelliJ and after 42 minutes the sync was complete.
So maybe that was the waiting time already. :slightly_smiling_face:

Hm, interesting, can you somehow debug that code?
When I set a breakpoint and either use IntelliJ "Debug", or `--debug-jvm` it is not hit.

I just configure that gradle tadk in ij and then run debug worked just fine

Use gutter arrow to run this test in debug mode <https://github.com/mpetuska/kotlin/blob/2169ba78ed0321899e9d1f084026e2a6dea4e360/libraries/tools/kotlin-gradle-plugin-integration-tests/src/test/kotlin/org/jetbrains/kotlin/gradle/JsConfigurationCacheIT.kt#L44>

<https://github.com/mpetuska/kotlin/blob/2169ba78ed0321899e9d1f084026e2a6dea4e360/libraries/tools/kotlin-gradle-plugin-integration-tests/src/test/kotlin/org/jetbrains/kotlin/gradle/testbase/testDsl.kt#L81> is a good place to put a breakpoint to be able to inspect test project outputs before JVM removes them

And my intended breakpoint is at `KotlinWebpackRule` line 38

Hmm, looks like ij didn't import your project properly

Try syncing again or invalidating caches?

JsIrConfigurationCacheIT_testBrowserDistribution_run_xml.xml

Otherwise here's my run configuration file (just drop it in `.run` folder at the root

And I recommend breaking at KotlinWebpackRule#L64 as thats where the main work is happening (assuming it gets instantiated succesfully in the first place)

It does not, that's the point.
At least the error I get is where my breakpoint is, when `enabled.convention(false)` calls `getEnabled()` which tries to use the object factory service which it states is not available.

I think I got those too, but found them misleading. Error persists even if you comment out all interactions with properties

i.e. that's not what's causing the error imo

I guess they are not misleading but already a first symptom of the problem.
Your problem is that the classes cannot be instantiated, isn't it?

But the errors implied that they were instantiated and failed during execution

Not what I get here:
```org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':kotlinNpmInstall'.
	[...]
Caused by: org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreationException: Could not create task ':rootPackageJson'.
	[...]
Caused by: org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreationException: Could not create task ':app:browserProductionWebpack'.
	[...]
Caused by: org.gradle.api.reflect.ObjectInstantiationException: Could not create an instance of type org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpackCssRule.
	[...]
Caused by: org.gradle.internal.service.UnknownServiceException: No service of type ObjectFactory available in DefaultServiceRegistry.
	at org.gradle.internal.service.DefaultServiceRegistry.get(DefaultServiceRegistry.java:291)
	at org.gradle.internal.instantiation.generator.ManagedObjectFactory.getObjectFactory(ManagedObjectFactory.java:121)
	at org.gradle.internal.instantiation.generator.ManagedObjectFactory.newInstance(ManagedObjectFactory.java:86)
	at org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpackCssRule_Decorated.getEnabled(Unknown Source)
	at org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpackRule.&lt;init&gt;(KotlinWebpackRule.kt:38)
	at org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpackCssRule.&lt;init&gt;(KotlinWebpackCssRule.kt:26)
	at org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpackCssRule_Decorated.&lt;init&gt;(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.gradle.internal.instantiation.generator.AsmBackedClassGenerator$InvokeConstructorStrategy.newInstance(AsmBackedClassGenerator.java:1969)
	at org.gradle.internal.instantiation.generator.AbstractClassGenerator$GeneratedClassImpl$GeneratedConstructorImpl.newInstance(AbstractClassGenerator.java:468)
	at org.gradle.internal.instantiation.generator.DependencyInjectingInstantiator.doCreate(DependencyInjectingInstantiator.java:64)
	... 227 more```

To be hones I've tried so many different things to get it working yesterday that I got them all mixed up already

Gradle is amazing when it works, but when you start getting reflection errors like these hair starts to fall off quick!

Well, I referred to software development in general. :smile:
But well, it is at least much nicer to work with than when you try to extend Maven :slightly_smiling_face: or worse, doing so and having problems

Never did never will. Is it really much worse?

Never did much with it either thankfully.
I basically always tried to avoid Maven.
I used Ant / Ivy until Gradle came up. :slightly_smiling_face:

But Maven is pretty much a big black box where you have a hard time if something goes havoc when with Gradle you can easily debug and find out.
Overly simplified of course. :smile:

Hm, look what I just stumbled upon: <https://github.com/gradle/gradle/pull/18260>

That probably explains it, as you test against 6.9 and 7.0 iirc.
And that PR made it into 7.3 RC 1

Oooh, gotta remember to circle back and check with 7.3 once that's out

And I just confirmed, I downgraded to 7.2 where I have used it and get `org.gradle.internal.service.UnknownServiceException: No service of type ObjectFactory available in default services.` where it works perfectly fine with 7.3.2

Ah :man-facepalming: Good to know it wasn't all just my code then :smile:

And it is not in the constructor here, but when I actually configure the extension and try to set a property.

I also found it extremely annoying that adding Named interface to noarg abstract class errors complaining that getName() is not implemented where all other object factories just implement it for you

Oh, while I have your attention, do you have any good links to read up on Namer usage? How do I inject it into the object containers?

&gt; I also found it extremely annoying that adding Named interface to noarg abstract class errors complaining that getName() is not implemented where all other object factories just implement it for you
Maybe same root problem?
Because when I made my interfaces abstract classes and the properties abstract it still worked fine.

Do you have Named interface actually implemented or just attached?

It was just like this:
```abstract class Base : Named {
    abstract val url: Property&lt;String&gt;
}
abstract class Foo : Base {
    @get:Inject
    abstract val objects: ObjectFactory

    abstract val children: DomainObjectSet&lt;FooChild&gt;

    fun child(nick: String) {
        children.add(createChild(nick))
    }

    private fun createChild(nick: String): FooChild {
        return objects.newInstance&lt;FooChild&gt;().also { child -&gt;
            child.nick.set(nick)
        }
    }
}
abstract class FooChild {
    abstract val nick: Property&lt;String&gt;
}
abstract class MyExtension {
    @get:Inject
    abstract val objects: ObjectFactory

    val baz = objects.polymorphicDomainObjectContainer(Base::class).apply {
        registerBinding(Foo::class, Foo::class)
    }
}```

&gt; Oh, while I have your attention, do you have any good links to read up on Namer usage? How do I inject it into the object containers?
No, but what do you mean how to inject?
Iirc if you have an object that is not `Named` you can alternatively supply a `Namer` for your child type so that the name can be derived.

Yeah, how do I supply it exactly. namer property in all the containers is immutable after instantiation

Why would you want to change it after instantiation?
The naming strategy should not change during the lifetime of the container.

Because I do not know any other way :smile: I basically need to provide my own namer, but none of the ObjectFactory functions allow me to do that. So my next though was ok, I'll set it straight after I construct the container

Is there some annotation that would allow me to attach a namer to my custom type?

Ah, now I know what you mean.
Didn't actually use a `Namer` yet. :disappointed:

Should be, otherwise what's the point of the interface? :smile:

Even DomainObjectContainer docs mention Namer as an alternative

Wouldn't be ther first class they have in the public API part accidentally :smile:

Oh, I'll make a note to expect such things moving forward then

Nah, better ask for it or complain, then it can either be fixed, documented, or moved to internal. :slightly_smiling_face:

&gt; Even DomainObjectContainer docs mention Namer as an alternative
Where?
Especially as that class does not exist :smile:

I meant `Named`DomainObjectContainer. But I'm guessing you got that already

Even there I don't find any mention of `Namer` besides the `getNamer` method

Hmm, might be confusing it with something else, but I could swear I saw multiple references to Namer in "some" docs

Ah, well, `Namer` must of course be public API even if you cannot supply one, unless methods like `getNamer` are moved to internal too.

At least the default object factory code does not look like you are able to somhow inject something custom.

Unless you construct your own container implementations, which is a colossal task!

Better just make your element implement `Named` or if it is a `Map` have a `name` key or actually just have a property `name` even if it does not implement `Named`

The `Named` interface is probably actually most useful if you want Gradle to just implement it for you.

Agreed, when it works of course (unlike in this pesky case) :smile:

Yep, well it works, if you do not use `registerBinding` :smile:

It's the same with for example abstract task classes or managed properties.
If you want to support older Gradle versions, you cannot have them.

&gt; Yep, well it works, if you do not use registerBinding :smile:
Not really, I still had to implement them properly and annotate my constructor with @Inject which made my kotlin classes ugly. There really should be `@constructor:Annotation` selector so I could at least put those annotations on top of the class

I guess that is just a product of you being desperate to fix it and trying out various things.
I'd guess as you use `ObjectFactory#newInstance` now, it should also work to just declare that you want to have `Named` implemented.
Because `ObjectFactory#newInstance` should do the same that `registerBinding` does from 7.3 on

I think you should be able to just remove the `getName` override in `KotlinWebpackRule` and the constructors and it should probably just still work

... and look nicer :slightly_smiling_face:

BTW, I lost count of how many times my IDE plain crashed while trying to run anything on that project... I suspect JB recent focus to cloud development might've been sparked by Kotlin repo :smile:

Didn't see any crash :slightly_smiling_face:

You're either lucky or have a beefy PC. My ~8GB~ 16GB ram with few browser tabs openned cannot handle it

I don't think there is one. You could leave a file somewhere, and check its modification time

but how could I make then the task as not already done?

I was already thinking about an input with the current date

Do you want to not execute the task for 24 hours even if other inputs or outputs changed?
Or do you want to rerun the task as soon as any inputs or outputs changed but additionally if 24 hours have passed?

I want to force that the task is executed after 24 hours again even if no other inputs are changed. If other inputs are changed it should be executed directly as expected

There are multiple options.
One is having the date as input property as you suggested, but that could of course mean, that if you execute at 23:59 it will be executed again on 00:01.
Another one is saving the last execution time in a file output and then in `outputs.upToDateWhen { ... }`  check whether the 24 hours have passed.
I wouldn't use the file modification time though, but just write the time to the file and read it from there.

Would you say that using the creation time is safe too? I am aware that the modfication time is not written on some file systems

That's not the only point. If you for example use build cache, both times are irrelevant. I stick with my recommendation, write the date to a file.

something like this for Kotlin?
```abstract class MyPlugin : Plugin&lt;Project&gt; {
	override fun apply(project: Project): Unit = project.run {
	}
}```

What's the benefit of `run` over `apply` here?

conventional, following how many of Gradle’s plugins are written.  run and apply are mostly equivalent, except for the return value (run allows for flexible returns), but that isn’t relevant here.

yeah, I know it, but there is aa class which does that without having to use apply or run

```abstract class BasePlugin(private val action: Project.() -&gt; Unit) : Plugin&lt;Project&gt; {
    override fun apply(project: Project): Unit = project.action()
}```
?

yw, just made this up :slightly_smiling_face:

I think that, or one similar to that is already available in Gradle

At least not that I know of, but that means nothing :slightly_smiling_face: