Why does the `testing.suites` container not get ac...
# plugin-development
e
Why does the
testing.suites
container not get accessors for kotlin dsl?
v
Accessors are only generated for things present by simply applying the plugin without further configuration. So any additional test suites you add cannot get accessors, except if you register them in some plugin you apply maybe.
e
Yes I know that but the
test
suite registered by default by the testing base plugin does not get accessors also so I don’t see the guarantee that my custom plugin will get them 🤔
v
Ah, right. I think it only works for extensions and extensions on extensions. But
suites
is a named domain object container and I think for those no accessors are generated. Maybe good candidate for a feature request if there is none yet.
e
🤔 Hm, I wouldve thought this would fall under “Elements in project-extension containers” mentioned here where the project extension is
testing
and the container is
suites
v
Hm, maybe I remember wrongly
g
Usually gradle generated accessors for elements in
NDOC
if they are created/registered in some plugin that you apply. At least it was a case for `TasksContainer`/`SourceSetsContainer`. I prefer to use explicit named/by existing/by getting though. It's not just IDE shows red but it doesn't run/compile if you try to use just
test { .. }
or
test.configure { .. }
?
e
Thats exactly what I am saying 🙂. That
test
suite is created by the test suite plugin. Still no accessors generated for it. I also used
named
to access & configure it just below
g
Since you posted screenshot and I couldn't differentiate between absent accessors and IDE not finding an accessor. For example IntelliJ IDEA regularly loses accessors for configurations and I have a lot of red in dependencies config when really all is well
e
Yeah youre right @grossws. I also faced that issue with IJ / AS before where it doesnt index accessors or something. This screen shot was just to give more info about OP.
👍 1
g
Just tried that. Only
TaskContainer.test
and
SourceSetContainer.test
were generated( And I've found no issues on GitHub either about test suites accessors or polymorphic named domain object containers.
1
e
Yeah thats the reason for my initial question. Is it by design or is it a bug somewhere in Gradle?
g
I guess they have to write accessor generator on case by case basis. Currently generated accessors are quite different for different containers (e.g.
*ConfigurationAccessors.kt
even have generated javadoc and generate extension methods for different receivers like `DependencyHandler`/`ArtifactHandler`/etc). Doesn't looks like it's a bug more like just an absent feature ,)
v
I played with it a bit. I think "Elements in project-extension containers" means containers that are directly extensions on the project, or are extensions on extensions, but the container has to be added as an extension. If I for example have
extensions.add("testSuites", project.extensions.getByType<TestingExtension>().suites)
in a plugin, I get accessors for
testSuites.test
and
testSuites { test { } }
. And if I have
interface Foo : ExtensionAware
and
extensions.create<Foo>("foo").extensions.add("testSuites", extensions.getByType<TestingExtension>().suites)
then I get accessors for
foo.testSuites.test
and
foo { testSuites { test { } } }
. But
suites
is a regular property on the
testing
extension and for that no accessors are generated. So as I said, if there is no feature request already, I guess a feature request to generate accessors for container properties on extensions would be necessary.
👍 3