Multi environment directory.

[alcarraz]

This is just food for thoughts.

Today I was playing around, to see if I can reuse a YAML environment, from a parent Gradle project. I came around with this hack.

The following Gradle excerpt, is just a POC.

tasks.register('testEndpoint', JavaExec) {
    workingDir "src/selftest/endpoint"
    classpath sourceSets.selftest.runtimeClasspath
    jvmArgs=['--add-opens=java.base/java.lang=ALL-UNNAMED', '-Djpos.envdir=../..']
    mainClass.set 'org.jpos.q2.Q2'
    args=['-Edist/cfg/devel','-Eselftest/endpoint/cfg/devel-test']
}

This is the relevant directory structure:

.
├── dist
│   └── cfg
│       └── devel.yml
└── selftest
    └── endpoint
        └── cfg
            └── devel-test.yml

I know I could copy the parent's YAML together with the selftest's one to an install directory. However, when debugging I prefer the code to run with the actual files, so if I modify them, the running Q2 takes the changes without additional steps other than saving the file. And I prefer not to modify the install version because then I forget, make a clean install and lose those changes.

If someone has another idea for my use case, please share.

This workaround works for me (and my particular workflow), but I was thinking, maybe there is some other use case for something like this. In that case we could have a path for looking for environments files, the jpos.env property could have a comma, (or a semicolon?) separated paths, like common operating systems.

If the same environment is in more than one directory of the same path, we may want to override completely the less priority ones, or we could inherit them, applying the properties from the least precedence to the most precedence. Or that could be a flag, yes I know, it may be too many options, over complicating the code, but since we cannot unset a property by overriding it, it might make sense.

If that's a feature found useful, I could try to create a PR implementing that, in a back portable way, provided you don't have the separator as part of a directory path you are using with jpos.env 😁. Or we can find better options if there is interest, of course.

I was also thinking about adding the possibility to import another YAML, with a given reserved property, perhaps we could define a reserved prefix for reserved properties, e.g., _jpos_.. And then we could write something like this:

_jpos_.env.import: devel

This would be for the use case where some environment is meant to always inherit another, so we don't have to pass both in the command line / build script / IDE debug configuration. This is not something I need, but when thinking about the other thing, the idea came to my mind.