Command line parameters as part of rules model inputs

Help/Discuss
1

Right now, it seems like the way to pass in properties to a build is by either using the -P command line option, or by using the @Option as part of a task input.

I’m interested in knowing how command line inputs will be used and reflected in the software model? Will they be considered another input to the build with some sort of binding to a rule?

Another part that comes to mind is the gradle.properties file. How are these represented in the model space?

2

get anywhere with this? i am dealing with the same issue. It seems that the model is loaded before the command line parameters. But thats just wild speculation right now.

3

I haven’t done a huge amount with this, but we have done a few things around this which seem to work.

User specifying in the build.gradle

If a user needs to inject parameters at build time, it seems like they can inject them at configuration time:

model {
  myObject(ManagedObjectType) {
     managedPropertyValue = project.findProperty('project.property')
  }
}

Usage in rules

The way we were able to expose properties during the model was introducing a sort of Proxy extension that we register in . Here is a quick example written inside a build.gradle:

import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.api.plugins.ExtensionContainer
import org.gradle.model.Model
import org.gradle.model.ModelMap
import org.gradle.model.Mutate
import org.gradle.model.RuleSource

class PropertyProxy {
  private final Project project

  PropertyProxy(Project project) {
    this.project = project
  }
  
  def findProperty(String propertyName) {
    project.findProperty(propertyName)
  }
}

class PropertyProxyPlugin implements Plugin<Project> {
  @Override
  void apply(final Project project) {
    project.extensions.create('propertyProxy', PropertyProxy, project)
  }
  
  static class Rules extends RuleSource {
    // ExtensionContainer is hidden using Gradle's internal @Hidden
    @Model
    PropertyProxy registerPropertyProxy(ExtensionContainer extensions) {
      extensions.getByType(PropertyProxy)
    }
    
    @Mutate
    void dependOnProxy(ModelMap<Tasks> tasks, PropertyProxy propertyProxy) {
      // use proxy as dependency
    }
  }
}

We haven’t used it extensively, but we have not ran into any problems yet.

4

Nice work @mkobit. I did encounter such limitation with the software model in the past.

I worked around the limitation using the JVM system properties (flag -D). You can pass in properties accessible through System.getProperties. This is accessible within the software model as well as from the init script. You can even define them in gradle.properties files by prepending each property with systemProp.. This is documented here in the user guide.

Keep in mind that @Option is an internal API which should be avoided if possible. However, feel free to raise an issue on Github for any feature request you feel can improve your work as Gradle user and plugin author.

I hope this helps with this limitation,

Daniel