Introduce support for OS-specific standard cache directories

[soc]

This cleans up the home directories of users and helps making sure that
Coursier's cache is not accidentically backed up by applications or OS
functionality.

The precedence is as follows:

• existing $COURSIER_CACHE environment variable
• existing coursier.cache Java property
• existing ~/.coursier/
• existing operating system specific standards:
  • Linux: $XDG_CACHE_HOME/coursier, with fallback to ~/.cache/coursier
  • Windows: {SpecialFolder.LocalApplicationData}/cache/Coursier
  • macOS: $HOME/Library/Caches/Coursier

[alexarchambault]

@soc Shouldn't dataDir used here, instead of cacheDir? XDG base directory spec says that the cache dir is for "non-essential data files", whereas dataDir is for "user specific data files". I feel like the latter would be a better match (the "cache" of coursier consists of data files, and I wouldn't say they're "non-essential").

I mean the coursier cache would be in a sub-directory of dataDir.

[alexarchambault]

About the precedence, I think the last two points should be permuted, like

• if OS specific dir for coursier exists, use it,
• else if ~/.coursier exists, use it,
• else, if none exists, fallback to OS specific dir.

That way, running a previous version of coursier (which would create a ~/.coursier) wouldn't change the cache directory for the later versions (which would pick the OS specific dir if it's there, no matter the ~/.coursier).

[soc]

@alexarchambault

Shouldn't dataDir used here, instead of cacheDir?

No, not in this case. There is no platform-independent way to avoid moving GBs of cached files across the network if you put them into the data dir (only Windows supports the distinction with roaming vs. local application data).

Cache is the right folder, because it perfectly fits the distinction of "the only thing users see after deleting the cache is that some things take more time".

On the other hand, packages that are published locally should go into the dataDir, as they are likely not recoverable from the online repositories.

This way, users have the huge benefit of being able to delete their caches without losing their locally published artifacts, and have their locally published artifacts synced across machines without dragging GBs of cached artifacts along with them.

About the precedence

Makes sense, I can change that.

Compile main sources with Java 6

Ooops, sorry I ported directories to Java 6 in dirs-dev/directories-jvm@ed193b4 already. I didn't see your PR. :-/ Please let me know if there are any required changes remaining.

[soc]

I made these changes to separate figuring out the various directories in CoursierPaths from the way they are used CachePath.

This way dealing with "v1" makes it easy for Coursier to potentially upgrade to a "v2" layout later, without breaking everyone's environment settings pointing to the "v1" dir.

The idea is that you only need to adapt defaultCacheDirectory to use "v2" and be done without having to write migration code and documenting how users need to change their environment variables.

[alexarchambault]

Ok, let's go for cacheDir then. (That's right that it makes no sense to somehow sync / save the cache dir of coursier, so it's better there.)

And, yep, I'm going to revert my commit about v1. It's better to put the cache in a sub dir of the cacheDir returned by directories (to separate it from other things that could be kept in cacheDir), and I can't think of a better name (and v1 is shorter than e.g. downloads).

[alexarchambault]

@soc Merging, thanks for having pushed for that!

[soc]

@alexarchambault It has been a pleasure!

Did you have any chance yet to verify that the paths chosen by directories work fine on Windows? (Mac, too, but I have less concerns there, because the solution to derive the directories is substantially less complex than Window's "let's tell the JVM to tell the OS to run a new process, run PowerShell in that process and then call functions from .NET").

[alexarchambault]

@soc The Windows CI didn't complain, I'm guessing things work fine there.

[alexarchambault]

@soc Where cache files land on Windows 10 (in a free VM):

[soc]

@alexarchambault This agrees with http://doc.qt.io/qt-5/qstandardpaths.html, but I would love to know how they came up with this path in the first place. Can't find anything in the Microsoft documentation.