https://gradle.com/ logo
Join Slack
Powered by
Is there any way to do a lazy map on `NamedDomainO...
# community-support
j
Is there any way to do a lazy map on 
NamedDomainObjectCollection
? This is returning a list with only 
metadata
as target, but if I use 
configureEach
, I know there are more targets
Copy code
the<KotlinMultiplatformExtension>().targets.map(KotlinTarget::getName)
v
A 
NamedDomainObjectCollection<X>
is-a 
Collection<X>
, so if you call 
map
on it, it is the standard Kotlin 
map
on 
Collection
that only gives you what is currently there. What is the use-case, what do you in the end want to do with that mapped collection?
j
Getting the list of target names lazily. I am still having problems with ordering because 
srcDirs
is not using lazy APIs tho... I am getting the targets inside a 
setProperty
lambda, so it should be already lazy, but I am probably calling 
get
too early
v
How about something like 
...configureEach { ...srcDir(it...) }
?
To answer the concrete question, I'm not aware that there is some lazy mapping ability currently. I might be wrong of course. 😄 Maybe you should create a feature request for something like 
.elements
on 
FileCollection
with which you can make a lazy mapping for the live elements of a 
FileCollection
as you get a 
Provider<Set<FileSystemLocation>>
, so you could get a 
Provider<Set<X>>
from a 
DomainObjectCollection<X>
that you then can map lazily.
j
Probably the 
configureEach
should be the best approach, but I would still love to see all APIs migrated to accept 
Provider
tho, it simplify a lot to work on any Gradle configuration
👌 1
v
I would still love to see all APIs migrated to accept 
Provider
tho
You mean like this hopefully coming in Gradle 9: https://github.com/gradle/build-tool-roadmap/issues/28 ? 🙂 Still the mentioned feature request might make sense, as this is not about something not accepting a provider, but a way to transform a domain object collection into a live provider.
Actually, you might be able to use 
provider { the<KotlinMultiplatformExtension>().targets.map(KotlinTarget::getName) }
as long as you do not 
get()
the 
Provider
too soon, as usual
Such a provider would be live and if properly evaluated as late as possible, optimally only at execution time, it should work
j
Indeed I am doing this 
provider { the<KotlinMultiplatformExtension>().targets.map(KotlinTarget::getName) }
(with 
setProperty
), but the problem is what you mentioned, I was forced to call 
get()
, and I was doing it too soon (something complicated to see in a convention plugin).
v
What makes you think 
srcDir
does not accept a provider currently?
Seems to work fine
j
Mmm last time I tried it was not working
Let me try again
Ah, I am using srcDirs + SetProperty
v
I just tried with 
srcDir
and a provider providing one directory, and 
srcDirs
with a provider providing a list of directories
What is 
SetProperty
?
Ah, a 
SetProperty
instance
👍 1
But a 
SetProperty
is a 
Provider<Set<*>>
, so with 
srcDirs
it should work
j
A bit weird then, I am going to remove the issue
v
I said should, first try to verify my babbling before you remove the issue 😄
But yeah, seems to work fine here. I tried with
Copy code
val foo = objects.setProperty<String>()
foo.add("src/functionalTest")
sourceSets {
    main {
        java {
            srcDirs(foo)
        }
    }
}
foo.add("src/functionalTest2")
And both directories were considered by 
compileJava
You should not close the issues as "completed", but as "not planned" ;-)
j
I can confirm it is working, not sure then what was the problem, maybe a different combination (
Provider<File>
?) but who knows
v
🤷‍♂️
j
You should not close the issues as "completed", but as "not planned" ;-)
Sadly I always forget that is the default behavior...
v
srcDir
with 
SetProperty
maybe (instead of 
srcDirs
)
I mean when failing
j
I don't think so, but I cannot confirm that, I saw the problem years ago and I started to think lazy APIs were not supported, if I see it again I will report.
v
Well, from years ago many things changed. Could well be that years ago it did not work. 😄 If you report an issue or feature request you should always verify whether it really still is like that in latest version. 😄
👍 1
p
👍 1
👌 1
j
@Vampire I found what I was referring, it is not 
srcDirs
it is 
setSrcDirs
v
Yeah, that only takes an iterable, which again hopefully changes in Gradle 9. But then just use 
setSrcDirs
to wipe and then use 
srcDirs
in the meantime
Copy code
val foo = objects.setProperty<String>()
foo.add("src/functionalTest")
sourceSets {
    main {
        java {
            setSrcDirs(emptyList<Nothing>())
            srcDirs(foo)
        }
    }
}
foo.add("src/functionalTest2")
👍 1
j
Yep that is the workaround I am using now and it is working :) thanks 🙏
👌 1
3 Views
Open in Slack
PreviousNext
Powered by