Configuring ml gradle

This page deals with how the ml-gradle plugin is configured. For information on how resource payloads are configured, please see Configuring resources.

ml-gradle is configured via two ways:

1. Properties in gradle.properties
2. Scripting in build.gradle

Of course, all of the files under src/main/ml-config can be considered configuration as well, but those are configuration files sent to MarkLogic. This page discusses how to modify how ml-gradle works, which includes what tokens it can replace in configuration files.

Properties

Gradle projects can be configured in a number of ways, most commonly via the gradle.properties file in the root directory of a project. Like many Gradle plugins, ml-gradle can be configured via a number of different properties in that file. Please see the Property Reference for a complete list of properties.

See Encrypting passwords for how Gradle can help with encrypting passwords that are stored in a Gradle properties file.

Environment-based properties

Gradle projects typically use the Gradle properties plugin to define different properties for different environments. See this sample project for an example of a basic dev/qa/prod setup using this plugin and ml-gradle together.

Important! Be sure that the Gradle properties plugin is always applied before ml-gradle. This allows the properties plugin to process the gradle-(environmentName).properties files before ml-gradle starts reading in properties.

Scripting

One of the main benefits of Gradle is that you can write any Groovy code that you want in build.gradle. One use case for this is to manipulate the objects that ml-gradle adds to the Gradle Project instance. You can see what these objects are in the MarkLogicPlugin class (that line number may change over time - look for the initializeAppDeployerObjects).

Each of those objects can be manipulated within a Gradle "ext" block. The most likely object to manipulate is the instance of AppConfig. A number of properties are set on an instance of class as described in the Properties section above. You can further modify this object as shown below, as there are getters/setters for all of its properties (though your best bet for now is to look at that link for AppConfig and see what setters are available by reading the code):

ext {
  mlAppConfig {
    contentDatabaseName = "my-database" // in case you don't like the default name that ml-gradle uses
    customTokens.put("%%MY_TOKEN%%", "some-value")
  }
}

The instance of AppConfig that's stored under the property name "mlAppConfig" is very important, as it's passed to each of the Command objects that are invoked when you run "gradle mlDeploy" and "gradle mlUndeploy". By manipulating a property on AppConfig, you don't have to know what command to modify or even what command uses the property.

If needed, you can always fiddle with the set of commands that are run during mlDeploy/mlUndeploy (this is shown in sample-project as well):

ext {
  mlAppDeployer.commands.add(new MyCommand()) // MyCommand would be a class defined in the build.gradle file
  mlAppDeployer.getCommands().remove(mlAppDeployer.getCommand("DeployRestApiServersCommand")) // remove a command that you don't want to use
  mlAppDeployer.getCommand("DeployContentDatabaseCommand").setDatabaseFilename("my-content-database.xml") // change the default database filename for the content database
}

The list of commands loaded into mlAppDeployer can be found in the MarkLogicPlugin class (look for the newAppDeployer method).

You can also create custom instances of tasks in ml-gradle that use slightly different settings, achieved by modifying the mlAppConfig object again:

task myCustomLoadDataTask(type: com.marklogic.gradle.task.data.LoadDataTask) {
  doFirst {
    mlAppConfig.dataConfig.permissions = "custom-role1,read,custom-role2,update"
  }
}

Bear in mind that if you were to invoke multiple tasks, changes to the mlAppConfig object will be seen by tasks invoked after the above one.