-
Notifications
You must be signed in to change notification settings - Fork 78
Configuring ml gradle
ml-gradle is configured via two ways:
- Properties in gradle.properties
- 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
The example projects, particularly the sample-project, in this repository show the different properties you can set in gradle.properties. For a complete list though, take a look at the factory class in ml-app-deployer that reads properties from a property source object (the PropertySource interface exists to hide where the properties come from - in ml-gradle, they come from the Gradle Project class, whereas in other environments, using system properties or a java.util.Properties may be desired). The AppConfig object produced by that factory is very important and is discussed below.
##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:
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).