https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
j
Usually, when you have to call 
get()
as part of the configuration, it it an indication that something can be improved. When you call 
get()
on a 
Provider
you may loose certain meta information – like which task is responsible for creating the value behind the provider. That's why the 
getAllFiles
task does not run automatically here. Instead your expression should start with: 
val zips = getAllFiles.map { ... }
In this setup you also do not necessarily need two tasks, but could directly use the configuration as input to `organizeTransitiveJsResources`: 
val zips = configurations.foo.elments.map { it.map { zipTree(it) } }
Note that this is always slightly confusing, because one 
map
is the 
Provider.map
of Gradle and the other is the 
Iterable.map
of Kotlin. I recently did a video on the topic that has an example very similar to this: https://github.com/jjohannes/understanding-gradle/blob/main/35_Working_with_Files/[…]gic/java-plugins/src/main/kotlin/my-java-application.gradle.kts
i
Ahah now I'm getting the opposite, it's now
Copy code
Cannot expand ZIP '/[…]/build/distributions/core-assets.zip' as it does not exist.
j
This is an indication that things are done too eager somehow (artifact is accessed before it is created). Die you use the 
configuration.foo
directly? There are a lot of eager methods and it is very easy to get it wrong unforuntately. E.g. you have to do 
foo.elments.map {}
(with 
elements
) which maps the configuration to the Provider API.
i
I wrote:
Ah, I see. But then I get a 
Provider<Provider<FileTree>>
which 
from
doesn't like
j
Yes that's a trap! The 
Configuration
API is historically full of traps....
🙌 1
transitveJsResources.map
is the Kotlin map (you don't want that)
transitveJsResources.elements.map
(the Gradle map)
(Hopefully we will soon see some deprecations and warnings)
i
It isn't 🙂 
transitiveJsResources
is a 
Provider<Configuration>
, it is 
Provider.map
j
Ah sorry.
Then the 
elements.get().map
is wrong 😄
but maybe it is okay... Mh.
I would do 
tJsRessources.get().elements.map {}
But the 
Provider<Configuration>
thing is also confusing to me. Configuration is already lazy. So that is double lazy. I don't know why that is a thing at all...
🤔 1
i
This fails with
Copy code
> Cannot convert the provided notation to a File or URI: [/[…]/build/distributions/core-assets.zip].
Also, you mentioned using 
get
isn't great here
j
In the above, do 
it.map { zipTree(it) }
because there you then have the list of Zip files
i
Oh, nice, it does work! Is there an easy way to tell it to keep the ZIP name as a root in the destination folder?
I mean that if the configuration resolves two ZIP files 
a.zip
b.zip
I would like to see the output
Copy code
build/
  extracted/
    a/
      (contents of a.zip)
    b/
      (contents of b.zip)
whereas currently I get
Copy code
build/
  extracted/
    (contents of a.zip)
    (contents of b.zip)
(all ZIPs are merged)
j
Good question. I can't think of a simple way to do that. The information about the jarFile name/path is lost the moment you do the 
zipTree
You could later do a
Copy code
from(...) {
  eachFile {
     path = "some-name/$path"
  }
}
But you don't know what "some-name" should be at that point anymore.
But it's a good question. I never wanted to do that. Maybe someone else has an idea.
i
Well, thanks a lot for everything 🙂 I now have got a MVP, I'll come back later to find a solution for that
v
As I said in your other thread, you might consider using an artifact transform instead. Then the unzipping logic and putting to subdirectory by file name is part of the artifact transform and your task will be back to a simple 
from(configurations.foo); into(destination)
.
3 Views
Open in Slack
PreviousNext
Powered by