stevesaliman
commented
10 years ago I disagree that it is misleading since the conversion from camel case to dot notation is clearly documented in the README.md, but I do agree that it can be confusing since Gradle properties are typically camel case.
Before I discovered the goodness that is Gradle, I came from an Ant background where properties are usually in dot notation. A tokenized file in the Ant world would have lines like this: some.property.name=@some.build.property@
Things are a bit different in Gradle where properties are more like variables, and use the typical Groovy camel case notation, but I wanted people converting from Ant to be able to continue to use the tokenized files they already had, so I chose to build the filterTokens variable with dot notation instead of camel case.
Plus the OCD fan in me thinks some.var.name=@some.var.value@ looked better to me than some.var.name=@someVarValue@ :-)
That said, I can now see how someone starting a project from scratch using Gradle is probably going to want to use the normal Gradle camel case values in the tokenized files.
I'll add make the change to have both kinds of properties in the filterTokens
I'm also thinking it would be nice to have all properties in the filter tokens, including ones defined inside the build.gradle file itself. I'll look into that enhancement as well if I get time.
I find a bit misleading to have automatic conversion of property names from camelCase notation to dot notation. Would it be possible to have a switch to leave the property names as they are declared in properties files?
Or, if it is not possible, maybe to populate project.ext.filterTokens with both original and converted values...