If a user tries to run the MMTC CLI with the lockfile.path missing from their config, MmtcConfig.getLockFileLocation() will resort to trying to create a lockfile in the same parent directory as the run history file. However, the acquisition of a lock file happens before config.validate() is called, so in the event a user is also missing the table.runHistoryFile.path key (or, more likely, has updated from 1.5.0 and hasn't renamed their key from table.runHistoryFile.uri), MMTC will throw an ambiguous NullPointerException that suggests they check the log (where no further details can be found).
Maybe also check for symmetry in acquiring and releasing a lockfile over the codebase, including around invoking MMTC with the 'migration' or '--help' or '--version' CLI options.
If a user tries to run the MMTC CLI with the
lockfile.pathmissing from their config,MmtcConfig.getLockFileLocation()will resort to trying to create a lockfile in the same parent directory as the run history file. However, the acquisition of a lock file happens beforeconfig.validate()is called, so in the event a user is also missing thetable.runHistoryFile.pathkey (or, more likely, has updated from 1.5.0 and hasn't renamed their key fromtable.runHistoryFile.uri), MMTC will throw an ambiguous NullPointerException that suggests they check the log (where no further details can be found).Maybe also check for symmetry in acquiring and releasing a lockfile over the codebase, including around invoking MMTC with the 'migration' or '--help' or '--version' CLI options.