Respect MAVEN_USER_HOME in MavenUtil

[dreamscached]

Hello! I am the maintainer of AUR packages for your software. I'm unsure if version 2 is still being maintained or you're occupied by work on v3, however, I have encountered a problem when packaging a VCS package for AUR.

The issue is about MavenUtil class which uses a hardcoded path for Maven local repository, which may be affected by MAVEN_USER_HOME or other Maven settings:

Recaf/src/main/java/me/coley/recaf/util/MavenUtil.java

Lines 168 to 173 in ca07fc0

	/**
	* @return Local directory containing downloaded maven artifacts.
	*/
	public static Path getMavenHome() {
	return Paths.get(System.getProperty("user.home"), ".m2", "repository");
	}

In my AUR package I resorted to use of the following patch:

171a172,173
>  		if (System.getenv("MAVEN_USER_HOME") != null)
>  			return Paths.get(System.getenv("MAVEN_USER_HOME"), "repository");

I think it wouldn't harm to also account for environment variable or Maven settings, if possible, instead of using hardcoded path. Thank you.

[dreamscached]

Originally it was an issue with tests being run and creating ~/.m2 folder without being told so, since Maven was set to use custom settings.xml which clearly defined that Maven home folder wasn't in ~/.m2 but somewhere else.

[Col-E]

I'm unsure if version 2 is still being maintained

That is correct, I am currently busy with v3. In fact, there's a heavy rewrite going underway. But with that in mind, outline all your needs and I'll see what I can do about addressing them in v3.

For awareness, v3 is going to be bumping the minimum version of Java required to run Recaf, most likely to 17.

The plan is to have a launcher module for users not using a package manager, and then publish the necessary files for repository maintainers to keep their own mechanisms for keeping up-to-date without the launcher.

Using the following patch

👍

Looks like a fine solution.