Allow configuration of directory into which content packages should be unpacked

Description

Currently, when content package is included in a distribution, it’s backend_config files are always unpacked into a subdirectory within the configuration directory named after the artifactId of the package.

So for the openmrs-content-hiv package, which has groupId=org.openmrs.content and artifactId=hiv, this will result in all of it’s backend_config files ending up in configuration/<domain>/hiv/*

However, in order to enable distributions to utilize content packages flexibly and without a lot of custom Maven configuration, it would be helpful to enable configuring where this is unpacked.

The proposal in this ticket is to support an additional configuration property in the openmrs-distro.properties file:

content.artifactId.namespace=

This will default to ${artifactId} as it does currently, though if this property exists it will use the value of the property instead. This means that - if the property exists and has an empty value, then it will install the configuration into the top level directory.

  • An empty value, a value of . or a value of / should be interpreted as the root of each configuration/{domain} directory

  • Any path that starts with . or / should be interpreted as starting from each configuration/{domain} directory, and those characters should be ignored.

End goal:

  • An implementation should be able to specify content.hiv.namespace= and the resulting distribution should contain all of the files from the backend_config of the hiv content package at the top level of their respective domain folders in the configuration directory.

  • An implementation should be able to omit this property entirely, and the resulting distribution should place all of the files within hiv subdirectories within each domain directory.

FYI

Activity

Mike Seaton 
December 6, 2024 at 8:51 PM

This has been addressed in this PR:
https://github.com/openmrs/openmrs-sdk/pull/317

FYI

Mike Seaton 
December 2, 2024 at 9:13 PM

Right, updated description.

Ian Bacher 
December 2, 2024 at 9:12 PM

One thing though: we currently namespace things on a per-domain basis, so presumably, / or . shouldn’t be interpreted as starting from configuration but from configuration/domain?

Ian Bacher 
December 2, 2024 at 9:11 PM

LGTM

Fixed

Details

Assignee

Reporter

Fix versions

Priority

Created December 2, 2024 at 9:07 PM
Updated December 11, 2024 at 3:01 PM
Resolved December 9, 2024 at 12:44 PM