build.gradle

/*
 * In order to use ml-gradle, it must be applied. This occurs after the two above blocks for overriding properties so
 * that those blocks can override properties before ml-gradle initializes itself.
 */
buildscript {
	repositories {
//		mavenLocal()
		mavenCentral()
	}
	dependencies {
		classpath "com.marklogic:ml-gradle:5.0.0"
	}
}

plugins {
	// The following plugins are optional

	id "net.saliman.properties" version "1.5.2"

	// The Java plugin is used to compile and run JUnit tests
	id "java"

	// These plugins are used to generate IDE files
	id "eclipse"
	id "idea"
}

apply plugin: "com.marklogic.ml-gradle"

/*
 * Everything below this line is optional and is intended to show different features provided by ml-gradle.
 */

/*
 * This lists the repositories for finding project dependencies (which differ from buildscript dependencies - buildscript
 * dependencies are not included in project artifacts that are built). These repositories are needed to satisfy the
 * dependencies expressed below.
 */
repositories {
	mavenCentral()
	mavenLocal()
}


configurations {
	// This custom Gradle configuration allows us to specify the classpath for running Corb jobs. This is only needed if
	// you want to run Corb jobs via Gradle tasks. More info on Corb can be found at - http://developer.marklogic.com/code/corb.
	corb
}

/*
 * This expresses dependencies on the ml-java and ml-junit libraries. The former is typically used for application
 * code, and the latter supports writing JUnit-based tests. A dependency exists on RestAssured to show an option for
 * using that library in tests that must invoke MarkLogic HTTP endpoints.
 */
dependencies {
	testImplementation "com.marklogic:marklogic-junit5:1.4.0"
	testImplementation "com.jayway.restassured:rest-assured:2.9.0"
	testImplementation "javax.xml.bind:jaxb-api:2.3.1"
	testImplementation "org.glassfish.jaxb:jaxb-runtime:2.3.2"
	testImplementation "org.glassfish.jaxb:jaxb-core:2.3.0.1"

	corb "com.marklogic:marklogic-corb:2.4.5"
}

test {
	useJUnitPlatform()
}

/*
 * ml-gradle adds an instance of com.marklogic.appdeployer.AppConfig to the Gradle project under the key "mlAppConfig".
 * This instance can be modified to affect the behavior of ml-gradle.
 */
ext {
	// mlAppConfig is an instance of com.marklogic.appdeployer.AppConfig
	mlAppConfig {
		// Example of adding custom tokens; these will then be replaced in any JSON/XML config files
		customTokens.put("sample-key", "sample-value")
		customTokens.put("%%ODBC_PORT%%", "8102")
		customTokens.put("%%XDBC_PORT%%", "8103")

		// XCC URL for running corb task below and for creating triggers on pre-8.0-4 builds of MarkLogic
		contentXccUrl = "xcc://${mlRestAdminUsername}:${mlRestAdminPassword}@${mlHost}:${mlRestPort}"
	}
}

/*
 * For tests that reference test files in the test source tree, we need to tell Gradle to copy these to src/test/resources
 * so that they can be found when running "gradle test".
 */
sourceSets.test.resources.srcDir 'src/test/java'

/*
 * This is an example of both a custom Gradle task and an easy way of invoking Corb. This depends on "mlLoadModules" to
 * ensure that the Corb uris/transform modules are loaded. It also uses as a classpath the custom configuration named
 * "corb" that we defined earlier. Note that the sample uris.xqy and transform.xqy modules just print a log statement
 * for each document in your content database, so unless there are documents, you won't see any result from this. You
 * of course can modify the transform.xqy module to perform any action that you would like - this is just to show how
 * to invoke corb from Gradle.
 */
task runCorb(dependsOn: ['mlLoadModules'], type: JavaExec) {
	main = 'com.marklogic.developer.corb.Manager'
	classpath = configurations.corb
	args = [contentXccUrl, '""', 'transform.xqy', '4', 'uris.xqy', '/ext/sample-project/corb/', 'sample-project-modules', 'false']
}

/*
 * The management API has an operation for loading the default CPF pipelines -
 * http://docs.marklogic.com/REST/POST/manage/v2/databases/[id-or-name]/pipelines. To load these as part of your
 * deployment process, just uncomment the line below. These pipelines will be loaded before your custom pipelines and
 * domains, which means you can safely reference them in your domain configuration files.
 */
ext {
	//mlAppDeployer.commands.add(new com.marklogic.appdeployer.command.cpf.DeployDefaultPipelinesCommand())
}

/*
 * Starting in ml-gradle 2.3.2, you can add as many JSON database file as you wish to the ml-config/databases
 * directory, and ml-gradle will process each of them. Prior to 2.3.2, if you want to create a database with a file
 * besides content-database.json, triggers-database.json, or schemas-database.json, you must also add a new instance
 * of DeployDatabaseCommand, as shown below.
 */
//ext {
//	def otherDbCommand = new com.marklogic.appdeployer.command.databases.DeployDatabaseCommand("other-database.json")
//	mlAppDeployer.commands.add(otherDbCommand)
//	mlDatabaseCommands.add(otherDbCommand)
//}

/*
 * Example of a custom command, which in this case performs a merge on a database. The benefit of doing this in a
 * command (as opposed to a task) is that a command can be included in the mlDeploy and mlUndeploy tasks by adding it to
 * the mlAppDeployer object, as shown below.
 *
 * This example also shows how the ManageClient instance in CommandContext can be used to easily make any call to the
 * Management REST API. Note that this class could also be defined in the Gradle buildSrc directory, which is really a
 * better option for keeping your build.gradle file slim.
 */
import com.marklogic.appdeployer.command.AbstractCommand
import com.marklogic.appdeployer.command.CommandContext

class MergeContentDatabaseCommand extends AbstractCommand {
	public Integer getExecuteSortOrder() {
		return Integer.MAX_VALUE;
	}

	public void execute(CommandContext context) {
		String dbName = context.getAppConfig().getContentDatabaseName();
		logger.info("Merging database: " + dbName);
		context.getManageClient().postJson("/manage/v2/databases/" + dbName, '{"operation":"merge-database"}');
		logger.info("Merged database: " + dbName)
	}
}

/*
 * Example of including our custom command in the deployment process. The order in which it's invoked is determined by
 * the command's "getExecuteSortOrder" method.
 */
ext {
	//mlAppDeployer.commands.add(new MergeContentDatabaseCommand())
}

/*
 * Below is an example of a custom task that merges a database - just like the command above. The benefit of creating a
 * task versus a command is that we can invoke this without running a full mlDeploy. The MarkLogicTask class provides
 * access to a number of helpful objects via methods like getAppConfig() and getManageClient().
 */
task mergeContentDatabase(type: com.marklogic.gradle.task.MarkLogicTask) {
	description = "Call this task to initiate a merge on the content database"
	doLast {
		getManageClient().postJson("/manage/v2/databases/" + getAppConfig().getContentDatabaseName(), '{"operation":"merge-database"}')
	}
}

/*
 * Example of attaching our custom task to the end of the mlDeploy process. mlPostDeploy is an empty task
 * that is called by mlDeploy after mlAppDeploy runs; mlPostDeploy thus allows for any additional tasks to be added to
 * the deployment process.
 */
//mlPostDeploy.dependsOn mergeContentDatabase