3.15.0

The main focus of this release is increased usage of the Configuration Management API to speed up application deployments.

Highlights of all issues in this release:

• Databases, protected paths, query rolesets, roles, servers, and users can all be deployed via CMA
• #355 An amp is not redeployed if it hasn't changed (this has a significant impact on Data Hub Framework projects)
• #357 ml-app-deployer now defaults to using CMA (if it is available) for all supported resource types except servers
• #360 To workaround a Manage API issue, if a scheduled task is created with task-enabled=false, a second call is made to the Manage API to ensure that the task is disabled (as the Manage API will make it enabled on creation)
• #361 "simple" SSL strategies now work correctly on Java 11+
• #362 ml-app-deployer now waits for a server restart after updating a task server
• Includes updates from ml-javaclient-util 3.13.0

3.14.0

Issues addressed by this release:

• #337 mlRestConnectionType and mlAppServicesConnectionType are now supported for creating DatabaseClient objects
• #338 New support for merging certain resource types from files across multiple config paths
• #342 Non-REST modules from multiple paths are now loaded in a single batch (this can be customized by setting the mlModuleLoaderBatchSize property, as it can lead to conflicting updates if the same module exists in multiple paths)
• #344 Fixed a bug with ensuring databases are deployed in an order based on their dependencies
• #345 A realm can now be specified when installing the admin user
• #347 Per ml-javaclient-util 3.12.0, the host is now included in the module timestamps file that's created when loading modules
• #349 Added support for generating a template file for a new trigger
• Includes changes in the ml-javaclient-util 3.12.0 release as well

3.13.0

Changes in this release:

• #333 TDE templates are now validated by default when they're loaded
• #335 The command for deploying certificate authorities now recognizes more file extensions
• #336 The property mlAddHostNameTokens can be used to make every host name available as a token for replacing in e.g. schedule task files
• #339 New support for loading data as part of a deployment
• #340 New support for installing plugins as part of a deployment
• #341 mlSchemasPath was deprecated in favor of mlSchemaPaths, which supports multiple paths
• Changes from ml-javaclient-util 3.11.0

3.12.0

This release addresses the following items:

• #313 The AppConfig class now has the concept of a project directory, enabling ml-app-deployer to work correctly within ml-gradle when running on Java 11 with the Gradle daemon enabled
• #330 Replica forests are now distributed more evenly across all hosts in a cluster
• #332 When creating a new REST API instance without a content database already existing, mlContentForestsPerHost is now correctly used to control the number of forests that are created

3.11.0

Summary of all issues:

• #319 Can now preview a deployment
• #308 Schemas can be loaded from database-specific directories
• #299 Amps can now be deployed via CMA by setting mlDeployAmpsWithCma=true
• #327 Privileges can now be deployed via CMA by setting mlDeployPrivilegesWithCma=true
• #325 When mlDeployForestsWithCma=true, all forests for all databases except the default content database (and optional test content database) will be deployed in a single request to CMA

3.10.1

This release includes a couple small enhancements in support of the upcoming DHF 4.1 release:

• #314 DeployOtherDatabasesCommand now has an extension point for providing a custom instance of DeployDatabaseCommand
• #315 JsonNodeUtil was refactored to expose a method for merging an array of ObjectNodes together

3.10.0

Summary of all issues

• #304 Default ML HTTP servers are no longer undeployed - e.g. you can have resource files for Admin and App-Services to modify their configuration; these files will be processed during deployment but not when the application is undeployed
• #310 Same as above but for default ML databases
• #306 Support for incremental deployments - see https://github.com/marklogic-community/ml-gradle/wiki/Incremental-deployment
• #311 Multiple scheduled tasks with the same task-path can now be deployed
• #312 mlModulesLoaderThreadCount now has a default value of 1, which means loading modules is single-threaded. This may avoid a bug with multi-threaded usage of the underlying digest authenticator in OkHttp. The use of multiple threads may have been a premature optimization as well, as testing with hundreds of modules has shown performance to still be fine.
• Fixes from ml-javaclient-util 3.10.0

3.9.1

This has a single bugfix in it - #307, the database-name property is not included when updating a database.

3.9.0

Highlights from the full set of issues:

• #276 Users can now be deployed via CMA by setting mlOptimizeWithCma=true
• #289 Flexrep pull configurations can now be deployed
• #298 Checking for the existence of a REST API group now accounts for the value of mlGroupName

3.8.3

Bugfix release with the following changes:

• #292 The "simple" HostnameVerifier now properly returns "true" instead of "false" in its "verify" method
• #294 AppConfig now provides restTrustManager and appServicesTrustManager fields
• #295 ManageConfig now provides securitySslContext for specifying an SSLContext for the security user
• #297 When a PUT or POST request fails, the request body is now logged
• Also includes ml-javaclient-util 3.8.1