Hi Andrii, I agree it would be useful to support YAML config reuse. It would allow users to have functionality-specific YAML config files and the finalized YAML can piece together the desired features.
Instead of ‘parent’ and ‘inheritance’ would it be better to support the concept of ‘import’ or ‘include’? The difference being that a child config would typically have a single parent and thus require a complex chain of parents to obtain the configuration from multiple files. In contrast, the idea of ‘import’ would support piecing together multiple config files without any limitation to number of imported files. Thoughts? Andrea From: Andrii Lomakin <[email protected]> Date: Wednesday, November 5, 2025 at 6:39 AM To: [email protected] <[email protected]> Subject: Proposal: YAML settings inehritance. Good day, colleagues. During the testing of our integration with Gremlin Server, I have noticed one hurdle. You should manually sync the configuration that you use for testing and production. That leads to subtle mistakes in testing that undermine the quality of QA routines. I propose implementing inheritance of YAML settings, a widely used feature. It can be implemented using the same com.fasterxml.jackson.databind.ObjectMapper#readerForUpdating functionality. I propose adding the parentSettings property to the YAML file schema, which should point to the initial settings file, either using the classpath: prefix or directly to the file system path. It will also allow us to provide settings templates for different use cases that should not be copied and pasted, but merely specified by users. WDYT?
