A further request is to resolve tokens so that I can define tokens that reference other tokens and expect them to resolve.
So if the file has host=localhost url=http://@host@ Then url would resolve to http://localhost. This is necessary for the DRY code. Shall I make a JIRA for this as well? Jesse On Thu, Mar 25, 2010 at 11:54 PM, Jason Porter <[email protected]>wrote: > On Wed, Mar 24, 2010 at 19:07, Adam Murdoch <[email protected]> wrote: >> >> >> A couple of days ago I added CopySpec.expand(Map properties), which adds a >> filter that runs the input files through a SimpleTemplateEngine with the >> given properties, eg >> >> processResources { >> expand(key1: 'value1', key2: 'value2') >> } >> >> Replaces property references, such as ${key1}, plus you can use all the >> other good stuff that SimpleTemplateEngine provides, eg ${key1 ?: >> 'unspecified'} or <%= classpath.join('\n') %> >> >> We could extend expand() to accept any number of parameters: >> - A Map would be used as is. >> - Anything else would be passed to uri(), and a properties file loaded >> from the resulting URI. >> - The effective Map of properties would be assembled by adding the above >> Maps together, in the order specified (last entry wins for duplicate >> properties). >> >> This would let you do something like: >> >> processResources { >> expand(project.properties, 'staging.properties', ' >> http://someshared/resource', key1: 'value', key2: 'value2') >> } >> >> I guess expand() isn't the greatest name. Perhaps expandProperties()? And >> we could add a corresponding expandTokens() which accepts the same types of >> parameters, and runs the file through ReplaceTokens filter with the >> assembled map of properties. >> >> >> -- >> Adam Murdoch >> Gradle Developerhttp://www.gradle.org >> >> Sounds really good Adam, the only other thing I would like to see is the > ability to specify the token delimiters, or have it do both tokens and > properties ('${...}', and '@...@' or whatever token delimiter you tell it > to). That way there would only be one method that would need to be called > that would fulfill probably 90% of the use cases for filters. We could > probably even go little further and expect a properties file somewhere > (either sourceSet.resources.srcDirs or in . ) called expandValues.properties > or something like that and use that file if it's available. That would make > processResources work for many people without even changing the default > task, or at least very little change required. > > I think having properties on the copy task to add to the defaults, like we > do in other places, would be best. There could be a tokens property, an > expandPropertiesSources, and possibly a flag to turn off expansion. > > > -- > Jason Porter > > Software Engineer > Open Source Advocate > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu >
