3

I need to set an ml-gradle property (mlModulesDatabaseName) within the build script itself. I was under the impression that the gradle-y way to do that was to use the extra modules extension:

ext {
    mlModulesDatabaseName = 'Modules'
}

This seems to place the value inside the project.properties map as it would if it was read from the gradle.properties, but its doesn't seem to target the correct database when I attempt to run the mlReloadModules task:

$ ./gradlew mlReloadModules -Pdev
:mlDeleteModuleTimestampsFile
:mlClearModulesDatabase
Clearing modules database
Logging HTTP response body to assist with debugging: {"errorResponse":{"statusCode":"404", "status":"Not Found", "messageCode":"XDMP-NOSUCHDB", "message":"XDMP-NOSUCHDB: xdmp:database(\"my-app-modules\") -- No such database my-app-modules"}}
Unable to clear database; cause: 404 Not Found
Finished clearing modules database
:mlPrepareRestApiDependencies
:mlLoadModules
:mlReloadModules

BUILD SUCCESSFUL

This may be ignorance of how gradle scopes its properties on my part, but you would think this would work. Any suggestions on how to pull this off?

3 Answers3

2

As far as i can remember ml-gradle reads properties immediately after being applied as a plugin. This means all changes to properties after this line

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

have no effect. Have you tried setting your ext properties before applying the ml-gradle plugin?

Edit: Another way to set custom properties is to set them like this:

ext {
    mlAppConfig {
        modulesDatabaseName = 'Modules'
    }
}

This also works after the apply plugin line.

Wagner Michael
  • 2,172
  • 1
  • 15
  • 29
  • Yup. That's what I was looking for. Both of these suggestions work for me. Thanks. – Craig Schlegelmilch Oct 02 '18 at 18:53
  • 1
    To clarify - when the ml-gradle plugin is applied, all of the properties are read in and used to set values on the AppConfig object that's referenced by mlAppConfig. So within an ext block, you can manipulate the mlAppConfig object. – rjrudin Oct 03 '18 at 11:56
0

I would recommend using the gradle properties plugin. Put something like this at the top of your build.gradle file if you don't have it already:

plugins {
  id "net.saliman.properties" version "1.4.6"
  id "com.marklogic.ml-gradle" version "3.7.1"
}

Once you have saliman properties plugin in place, you can drop your dev-specific properties in a file called gradle-dev.properties, and run with -PenvironmentName=dev to enable them.

By default it will look for both gradle.properties and gradle-local.properties. It will always read both the gradle.properties as well as the environment-specific properties file (if exists). The latter will override properties from the first.

Depending on the specific tasks, you can also override properties from within build.gradle, but I'd avoid doing that with tasks that come with ml-gradle out of the box.

HTH!

grtjn
  • 20,254
  • 1
  • 24
  • 35
  • For posterity, I should note that this is the better answer if you're engineering your gradle script properly. So anybody that is looking for a similar answer, I'd go this way. Sadly, I'm retrofitting ml-gradle into a legacy script that would make this hard(er) so I couldn't use it here. – Craig Schlegelmilch Oct 03 '18 at 02:27
0

I would like to share another approach which I use to run ml-gradle tasks within MarkLogic Data Hub Framework (DHF) projects. In DFH development, I sometimes need to run a same task on either the staging DB or the final DB. So I use a GradleBuild task to wrap around the ml-gradle task and set the project properties within the GradleBuild task.

task myFinalDbTask(type: GradleBuild) {    
  tasks = ['myMlGradleTask']
  startParameter.projectProperties = [
    database: mlFinalDbName,
    port: mlFinalPort
  ]
}
Fan Li
  • 1,057
  • 7
  • 11