I would like to setup the input (files to compress) and the archive name for the Zip task in a dynamic way (in the execution phase). As far as I’ve experienced and what I’ve read here this is not possible. The Zip task must be setup during configuration. Why? Whats the concept about it?
(if it’s just because of the up to date check then a switch to disable this behavior would be nice.)
The file tasks are convenience wrappers around project methods. For instance the Copy task invokes Project.copy(…). You can invoke methods directly on the Project instance
Eg:
Project.copy(…)
Project.zipTree(…)
Project.copySpec(…)
Project.delete(…)
etc, etc
If you’re invoking these manually I suggest you configure the task inputs/outputs accordingly
Yes, you’re right. Unlike unzipping, there’s no convenient way to zip other than using the zip task.
You could use either a doFirst {…} block or another task (and dependsOn) to dynamically initialize a folder to zip. Then the folder location can be static but the contents dynamic.
Perhaps a bit more info on what you are doing and the timings would be helpful to come to a solution to achieve the dynamic behaviour you require but still setting archiveName / source at configuration time.
I’m assuming you realise you can do something like:
I don’t have a static folder with dynamic content. I have a .txt file (written at runtime) containing the paths of files to compress. This file is read as a collection of files which then serves as input (from property) for the Zip task as an FileCollection.
So what I try to achieve is doing a Zip out of files which are defined at runtime. The Zip archiveName is read from a file which itself is created during the build (execution time) too.
task doRelease() {
doFirst {
[...]
// 'file' is written through build process
project.ext["version"] = (file =~ regex)[0][1]
[...]
}
// zipSources is from type: Zip
finalizedBy zipSources
}
In ‘zipSources’ if want to set this version as the archiveName which is not possible because at configuration time the version property is not available. Putting the setup of the Zip properties (like archiveName) in a doFirst{} etc. in the ‘zipSources’ task result always in an up-to-date for this task.
The same problem with the archiveName arises with the dynamic setup of the FileCollection I described at the beginning.
To summarize it, why it’s not possible to configure the Zip task during execution phase in a straight manner?