Copy/archive files multiple times with different filter configurations


(rainer.frey) #1

I’m looking for the most declarative / idiomatic / elegant way to achieve the following:

I have a directory of source files that contains (among others) some XML files with tokens to replace. I also have a set of property files which contain the values for these tokens, each file in a different language. I need to generate a zip archive per language (with the language in the archive and base directory name) of the said source directory, where the XML files have the tokens replaced by the values of one property file.

The property files themselves are also generated during the build, by one single generation task. Ideally that dependency should be inferred by task input/output.

Do you have any ideas on what would be the best way to set up the necessary archive tasks, which all have the same configuration pattern? The set of languages rarely changes, but it looks a bit smelly to list them explicitly in the build. But listing the property files can only be done in execution phase, as the build generates them. OTOH I can’t see a way to not have a task per destination archive, and AFAIK tasks can’t be added in execution phase.

Also, the property file would be an input to the archive task, but of course not as archive content. I should be able to register it directly with the task’s ‘TaskInput’ object, using the ‘file()’ method , right? Or would that interfere with the way the archive/copy tasks use it’s input objects? Would it be better to subclass the Zip task and define a specific property (which would be a code smell as well, as it would make it difficult to change the archive format).

In case it makes any difference: the copy filter itself is a closure which uses a custom class, as the ant filters don’t work for the token format.

I know how to implement such a task in general, this question is really about finding the way that’s easiest to comprehend and maintain in a long-term project build.

Thanks for any advice / ideas.

Rainer


(Peter Niederwieser) #2

I don’t see a need to subclass the ‘Zip’ task. Just loop over all languages and create an archive task for each. You can either hardcode the list of languages, or get it from the same information source that the properties generation task is getting it from. Registering the properties file as an input for the archive tasks is the right thing to do. In order for Gradle to deduce the task dependency automatically, you’ll have to refer to that file in an abstract way (e.g. ‘generatorTask.outputs.files’).


(rainer.frey) #3

Hi Peter, thanks that brought me on the right track.

One question though: the generator task produces all property files. For one archive task, I need to refer to one single property file.

Is there a way to find this from ‘generatorTask.outputs(.files)’ so that gradle does deduce the dependency, or should I state the dependency explicitly?


(andrew.l.mckee) #4

Is it possible to create tasks during runtime? For instance, I have a directory full of .war files, each of which needs its own .tar.gz file (weird, I know–don’t ask). Could I somehow loop the files and create Tar tasks for them to run even though configuration phase is over?


(Peter Niederwieser) #5

You can create tasks in a loop at configuration time. Tasks cannot be created at execution time. PS: This should have been a new topic.


(andrew.l.mckee) #6

Sorry for the resurrection. Thanks for the quick response. I think I’ll be able to push it up to configuration time and make it work.