Announcing a new plugin for loading properties

By default, gradle handles properties by looking in 3 places:

  1. The file in the project directory 2) The file in the user’s .gradle directory 3) The command line via -P arguments.

My properties plugin ( ) enhances this functionality by adding 2 new places to get properties:

  1. The file in the project directory 2) The gradle-${environmentName}.properties file in the project directory, where users can specify the environment they are using, such as “dev”, or “prod” 3) The file in the user’s .gradle directory. 4) The gradle-${ file in the user’s .gradle directory, if the user specified a gradleUserName 5) The command line via -P arguments.

This new way of loading properties offers significant flexibility over the default mechanism.

One of the challenges in configuring and building a project is that there are often properties that change from environment to environment. For example, the logging level is often finer grained in testing than it will be in production, or a project may need to consume services whose URL is different from environment to environment. It can also be a real challenge for a developer to find all the files that need to be configured for a particular environment, especially for a developer who is new to the project and needs to get it working on their box.

Another challenge is how to handle properties that span projects, and should not be checked in with a project, but still changes from user to user (or client to client). For example, you might have several projects that make up a suite of products. The products might have a customizable banner that should be different for each client. Rather than storing the same properties in each project, the properties plugin lets you set the banner in a single file, the specify at build time which client file to use.

The plugin also creates a project.ext.filterTokens property which can be used when copying files to set up the project. The project is Apache 2.0 licensed, and available on Maven Central. More details are available at the project home page.

I’ve also released a new Cobertura plugin ( ). There are other Cobertura plugins around, but this one is the only one I’m aware of that still runs the coverage reports after a test fails. It is also Apache 2.0 licensed and available on Maven Central.


Steve Saliman

Great work Steve. Thanks for the contribution.