https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
v
Action is enough for both. If something has both, then that's just for binary backwards compatibility
c
Then something is going wrong. I’m working on jooq’s new gradle-plugin, and it currently uses Closure<*> everywhere. After converting to Action<TheClass>, I can’t seem to get groovy to be happy
v
Is it the correct Action?
c
org.gradle.api.Action?
👌 1
Basically I was trying to put together an answer for https://github.com/jOOQ/jOOQ/issues/12985#issuecomment-1842575822
how to hint the closure structure to IntelliJ so it doesn’t trip and tries reporting random warnings?
And I was pretty sure that Action should be fine for groovy and kotlin
But in local testing I’m having troubles
Basically an example app sees
Copy code
A problem occurred evaluating project ':groovy-app'.
> Could not get unknown property 'database' for <logging>WARN</logging><onError>FAIL</onError><onUnused>LOG</onUnused> of type org.jooq.codegen.gradle.MetaExtensions$ConfigurationExtension.
kotlin sees all the types
but groovy starts getting confused
v
Do you have something I can open in the IDE?
c
Uh
sure I’ll push real quick
gonna push repro
basically mvn install on jooq (to get all the deps into maven local)
then in jooq the gradle plugin is a gradle project
which is includeBuilded by the repro repo
Ok further actual reading of the error message
Copy code
> Could not find method database() ... of type org.jooq.codegen.gradle.MetaExtensions$ConfigurationExtension.
Meaning the implicit 
this.
or 
it.
in groovy isn’t working 3 layers deep
when replacing database with it.database then groovy is happy
v
Yeah, naturally, but I thought it should also work without. 😕
c
I made a recursive example project to try to reproduce this and the action worked as expected.
it type checks in intellij too
so maybe there’s specifically something with how the jooq plugin is set up
v
I don't think your test applies. The problem was with accessing the inner properties, not the outer ones.
Assuming 
exampleName
is not on 
NestedConfig
but whatever 
example
delegates to
c
exampleName is only on NestedConfig
v
Ok, but even then you don't know on which this was called, was it really the most nested one?
c
!
Good point, I’ll create individually nested configs
Ok so I can repro this
But in kotlin dsl it works
v
Well, maybe something to report to Gradle, I don't know. 🙂
c
Thanks for being a huge help in debugging this, really appreciate it
👌 1
Ok I should have known that manually calling 
new Configuration()
is a bit weird in gradle where so many things revolve around making classes non-final or abstract. If 
new Configuration()
is replaced with 
objects.newInstance(Configuration::class)
then it doesn’t matter how nested the configuration objects get, groovy’s dsl can resolve the configuration objects.
So `Action<>`’s conversion to `Closure`s was working, but instead of calling 
action.execute(new NestedConfiguration)
, call something like 
action.execute(objects.newInstance(NestedConfiguration::class)
(and of course make sure to 
@Inject
the 
ObjectFactory
into every nested sub-configuration class).
👌 1
v
Yeah, you should always let Gradle construct domain objects, because you can save much boilerplate, you can inject things, all of them get 
ExtensionAware
automatically, ...
🤝 1
6 Views
Open in Slack
PreviousNext
Powered by