Releases · marklogic/ml-gradle

NB! In version 3.2.0, all Gradle properties are now by default available for token replacement in payload files and module files. Prior to 3.2.0, you had to manually add tokens to the mlAppConfig.customTokens map in order for them to be available. In 3.2.0, every property - not just ml-gradle properties, but all Gradle properties - is added with "%%" as the default prefix and suffix around the property name. Please see the documentation for more information.
Several new properties are available for creating forests.
DMSDK tasks now allowing for specifying a database via a property, so it's easier to use these on an ad hoc basis against any database (via port 8000).
Improvements from ml-app-deployer 3.2.0
Improvements from ml-javaclient-util 3.2.0

Assets 2

16 Nov 16:07

rjrudin

3.1.0

ba7dfd3

3.1.0

Full list of issues at: https://github.com/marklogic-community/ml-gradle/issues?q=is%3Aclosed+milestone%3A3.1.0

Nothing special to do for an upgrade - just bump up 3.0.0 to 3.1.0. If you're still on 2.x, see the 3.0.0 release notes for upgrade instructions.

Highlights:

Now using the MarkLogic Client API version 4.0.2, which uses OkHttp instead of Jersey for HTTP connections
Can now update databases without creating/modifying forests by including -PmlCreateForests=false
Modules can now be exported
New sample projects for redaction rulesets and a uni-temporal configuration without lsqt
Includes changes in ml-app-deployer 3.1.0

Assets 2

03 Sep 23:44

rjrudin

3.0.0

c5811d4

3.0.0

Version 3.0.0 of ml-gradle brings some new capabilities, particularly based on version 4.x of the MarkLogic Java Client API, but it also has some breaking changes from version 2.x, primarily based on some package reorganization in its dependent libraries.

New features:

Support for common ad hoc tasks across large numbers of documents via DMSDK
New and flexible file loading via REST API, optionally using new DMSDK in ML9
See the 3.0.0 release of ml-app-deployer for new features as well, which includes a number of new properties added to the Property reference page.
Full list of issues (note that ml-gradle has relatively few new issues; most of the work in this release was done in ml-app-deployer)

Breaking changes:

Some packages have been reorganized in ml-app-deployer, which is the library that ml-gradle uses for communicating with the Management REST API.
And a lot of packages have been reorganized in ml-javaclient-util, which is the library that ml-gradle and ml-app-deployer use for loading modules into MarkLogic, among other things.
See How modules are loaded for a change in how modules in "unrecognized" directories are handled. Note that it's best to put asset modules into either "ext" or "root", and you won't be affected by this change in behavior.

Here's the likely impact of those breaking changes (if you haven't made custom Gradle tasks, it's very likely that you're not affected at all):

You may have custom Gradle tasks that import/use *Manager classes from ml-app-deployer - the import statements will need to be changed as they're most likely importing the classes from the 2.x location and not the 3.x location. Generally, that change will be along the lines of importing from "com.marklogic.mgmt.resource.(resource type)" instead of "com.marklogic.mgmt.(resource type)".
You may also have Gradle tasks that directly access classes from ml-javaclient-util - those will need their import statements updated as well. See the release notes for ml-javaclient-util for more information.

Assets 2

07 Aug 21:33

rjrudin

2.9.0

9f9b4b5

2.9.0

All issues: https://github.com/marklogic-community/ml-gradle/issues?utf8=%E2%9C%93&q=milestone%3A2.9.0

And see the 2.9.0 ml-app-deployer release notes too.

Summary:

ml-gradle can now figure out what order to deploy roles in without having to name role filenames to order them.
ml-gradle can also handle deploying a role that refers to itself without having to break that up into two different payload files.
mlDeploy can now ignore commands
Exported users now have a default password in them so they can be immediately deployed without causing an error.
Amps can now be exported.
"validate-queries" and "validate-options" in a REST API properties module are now processed correctly

Summary of changes relevant to migrating a Roxy project to ml-gradle:

First, see the updated Roxy to ml-gradle guide
Roxy properties are now mapped to ml-gradle properties
Roxy source files can now be copied from a Roxy project into an ml-gradle project
Some custom Roxy build steps are automatically converted into Gradle custom tasks
One or more modules can be deleted after loading modules - this allows supporting Roxy's concept of deleting test modules in a production environment.

Assets 2