Describe the problem
Users of our JAR files currently have to add -DMAPTOL_DATADIR=.maptool-rptools to their command line in order to use the same data directory as would be used by one of the installed packages. If the option is not provided, it can cause confusion as the user's preferences, layouts, and resources may not be used. It also creates a redundant .maptool directory alongside any existing .maptool-rptools directory, despite them serving the same purpose.
The improvement you'd like to see
Update the Java code to make the default data directory .maptool-rptools instead of .maptool. If MAPTOOL_DATADIR is defined on the command line, use the provided directory instead.
Expected Benefits
This will be one less hurdle for JAR users to jump through while still allowing the option to relocate the data directory for those that explicitly want it.
Additional Context
There's a couple downsides / gotchas.
Existing JAR users: Anyone who has only ever used the JAR and never set -DMAPTOOL_DATADIR=.maptool-rptools will only have a .maptool directory. Changing the default would cause them to switch to .maptool-rptools unless they specify otherwise, which is just the reverse of the original problem statement. I would say this is acceptable since it will decrease friction for anyone new trying the JAR, and existing users can still specify -DMAPTOOL_DATADIR=.maptool if they wish. As long as we call this out in the release notes, it should be fine.
Data directory pollution during development Right now, development runs of MapTool use the standard .maptool-rptools directory (mostly). This isn't great since development behaviour can be very experimental and sometime incompatible with release builds. This might not sound related, but today test runs actually don't use that directory since they don't have the same command line parameters in effect - they actually use the default .maptool directory. If we make the most straightforward change of replacing ".maptool" with ".maptool-rptools" in AppUtil, then tests will also hit .maptool-rptools which sketches me out even more. This would be a good time to separate thing a bit more, with LaunchInstructions defaulting the MAPTOOL_DATADIR value to ".maptool-rptools" while AppUtil is updated to default to a separate development directory if MAPTOOL_DATADIR is not set.
Describe the problem
Users of our JAR files currently have to add
-DMAPTOL_DATADIR=.maptool-rptoolsto their command line in order to use the same data directory as would be used by one of the installed packages. If the option is not provided, it can cause confusion as the user's preferences, layouts, and resources may not be used. It also creates a redundant.maptooldirectory alongside any existing.maptool-rptoolsdirectory, despite them serving the same purpose.The improvement you'd like to see
Update the Java code to make the default data directory
.maptool-rptoolsinstead of.maptool. IfMAPTOOL_DATADIRis defined on the command line, use the provided directory instead.Expected Benefits
This will be one less hurdle for JAR users to jump through while still allowing the option to relocate the data directory for those that explicitly want it.
Additional Context
There's a couple downsides / gotchas.
Existing JAR users: Anyone who has only ever used the JAR and never set
-DMAPTOOL_DATADIR=.maptool-rptoolswill only have a.maptooldirectory. Changing the default would cause them to switch to.maptool-rptoolsunless they specify otherwise, which is just the reverse of the original problem statement. I would say this is acceptable since it will decrease friction for anyone new trying the JAR, and existing users can still specify-DMAPTOOL_DATADIR=.maptoolif they wish. As long as we call this out in the release notes, it should be fine.Data directory pollution during development Right now, development runs of MapTool use the standard
.maptool-rptoolsdirectory (mostly). This isn't great since development behaviour can be very experimental and sometime incompatible with release builds. This might not sound related, but today test runs actually don't use that directory since they don't have the same command line parameters in effect - they actually use the default.maptooldirectory. If we make the most straightforward change of replacing".maptool"with".maptool-rptools"inAppUtil, then tests will also hit.maptool-rptoolswhich sketches me out even more. This would be a good time to separate thing a bit more, withLaunchInstructionsdefaulting theMAPTOOL_DATADIRvalue to".maptool-rptools"whileAppUtilis updated to default to a separate development directory ifMAPTOOL_DATADIRis not set.