The

--build-file

option is deprecated and will be removed in 8. What is the alternative I should use to work with multiple

build*.gradle.kts

files? I think I need multiple build files… but maybe there is another solution. Let me explain my situation: • I need to import an ant file (btw this ant file is not under my control) • the ant file needs a jar with some custom tasks, otherwise the ant code will throw an exception • so: this jar needs to be downloaded before the ant file can be imported • so: my gradle script needs to download a jar before my gradle script can be read correctly…. huh? yeah catch-22! my conclusion is that I need to make two gradle files: 1. one that only downloads the jar with the custom ant tasks (

bootstrap.gradle.kts

) 2. one that imports the ant file and does the rest of the build (

build.gradle.kts

) then I need to call gradle twice: first using

--build-file bootstrap.gradle.kts

and then just a plain call of gradle. Since

--build-file

is deprecated this is not a future proof solution… Any hints appreciated.

Well, you can configure the build script name for a project in the settings script, so you could declare different build scripts for the project, for example depending on some Gradle property. But there might be cleaner solutions, but I guess an MCVE would help. For example how do you download that jar file? Can't you just define an Ivy repository with a layout that makes it compatible to download the jar and then use a dedicated configuration declare the jar, then you can resolve it even at configuration time if you need, for example.

You are so quick Björn! 😄 much appreciated! I am working with MPS from JetBrains, The jar is part of the install zip that my custom gradle plugin downloads from their download site…. alas not your regular maven repo… I will see if I can come up with a MVCE… Can I write my custom plugin in such a way that it will trigger a download before the ant file is imported? But would I then not download also on e.g. a

clean

task? (haha it would not be very productive to first download and install a zip only to have it removed immediately by

clean

...) I agree that my solution is more a workaround then a clean solution. Do you know what the status of the

--build-file

 option is? Does gradle 8 completely remove multiple build file support?

I have no idea, but as I said, either way you can anytime set different build script names for the project in the setting script, so you can easily compensate the missing option. Yes, if you download in your plugin apply code, that would also do it on

clean

. But you probably don't need to always download but can use a cached version? Using an Ivy repository, it does not have to "your regular maven repo". Ivy repositories are extremely flexible and configurable, you can download from virtually any place. As long as the place supports

HEAD

requests iirc, I think Gradle cannot do without them.

Sorry, I might not completely understand what you mean by “_set different build script names for the project in the setting script_”… Do you mean that I would make 2 settings files (e.g.

settings.gradle.kts

and

bootstrap.gradle.kts

) with different build scripts mentioned in them and that I could run gradle with

--settings-file bootstrap.gradle.kts

to select the proper settings file?But the

--settings-file

option is also deprecated…. how would that help? Or do you mean to have one

settings.gradle.kts

and select the name of the gradle script conditionally? Yes, I cache it, but still a waste of time to unzip 1.2G and then remove it immediately… 🥴 I did not know Ivy repos are that flexible… sounds like a neat toy, I will read up on them, thanks for the tip!

Or do you mean to have one 

settings.gradle.kts

 and select the name of the gradle script conditionally?

Yes, that's what I said. 🙂 To quote myself:

Well, you can configure the build script name for a project in the settings script, so you could declare different build scripts for the project, for example depending on some Gradle property.

Yes, I cache it, but still a waste of time to unzip 1.2G and then remove it immediately… 🥴

Indeed, so don't unzip it in your plugin code directly, but let an artifact transform do it. Then the unzipped files are in the transform results directory and not in your project, so are not affected by a

clean

🙂

Yes, that’s what I said. 🙂

hihi reading/understanding is difficult sometimes 😉 I think I understand now, I will try it out.

Indeed, so don’t unzip it in your plugin code directly, but let an artifact transform do it.

Then the unzipped files are in the transform results directory and not in your project, so are not affected by a 

clean

 🙂

trying to understand 🤯….. I am not too familiar with Transforms yet 😳. Let me check if I understand you correctly: • I do not need to put the unzipped files in the project build dir at all anymore • I can instead directly use the files in the transform results directory! • what I still have to solve is how to relay to ant where the files in the transform results directory are • the download and unzip will only happen once on a certain machine, the unzipped files are shared between all projects on that machine and they will survive any projects

clean

run ❗sounds like a plan!

Yeah, the transforms are a bit glitchy to get initially. But once you got the grasp, you also start to see the use-cases. I had a quite similar need when I started to use them. I needed to supply the a downloaded unpacked zip to an extension that needed the directory to be there unpacked at configuration time already. So roughly summarized: • you have a custom configuration • you have the transform that unpacks a zip and thereby transforms attribute A from value X to Y • you specify that all zips have the value X • you request for you configuration value Y • you declare the dependency on that configuration If you now resolve the configuration you in there don't have the zip anymore, but the exploded directory