You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jason van Zyl (JIRA)" <ji...@codehaus.org> on 2015/04/03 18:20:18 UTC
[jira] (MNG-5759) Change order of IF statements to determine
JAVA_HOME
[ https://jira.codehaus.org/browse/MNG-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MNG-5759.
------------------------------
Resolution: Fixed
> Change order of IF statements to determine JAVA_HOME
> ----------------------------------------------------
>
> Key: MNG-5759
> URL: https://jira.codehaus.org/browse/MNG-5759
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
> Affects Versions: 3.2.5
> Environment: Mac OS X/Darwin
> Reporter: Cory Steers
> Priority: Minor
>
> I'm running a run configuration in Eclipse/STS called "Mule Application with Maven" from Mulesoft. It does not appear to use the m2eclipse plugin or anything like it to pass in a JAVA_HOME environment. Thus, the mvn shell script in ${M2}/mvn is left to try and determine the JAVA_HOME environment.
> In my case, my Mac has the Apple Java 6 installs, but also has the Oracle Java 7 installs. The java preferences has 1.7 specified and the /usr/libexec/java_home variable returns "/Library/Java/JavaVirtualMachines/jdk1.7.0_72.jdk/Contents/Home"
> The mvn script first checks to see if /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK is a symlin/link at ~ line 61. It is, so it uses that to set JAVA_HOME. However, since every setting that I know to set has specified java 7, it's incorrectly setting JAVA_HOME to a 1.6 version, which is where the /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK link is pointing too.
> since /usr/libexec/java_home points to the correct environment, I propose that you move the if block ~ line 82 to above the first if block ~ line 61. Here's a diff against the current trunk:
> index 1ed3024..43b8304 100755
> --- a/apache-maven/src/bin/mvn
> +++ b/apache-maven/src/bin/mvn
> @@ -58,6 +58,13 @@ case "`uname`" in
> # Look for the Apple JDKs first to preserve the existing behaviour, and then look
> # for the new JDKs provided by Oracle.
> #
> + if [ -z "$JAVA_HOME" ] && [ -x "/usr/libexec/java_home" ]; then
> + #
> + # Apple JDKs
> + #
> + export JAVA_HOME=$(/usr/libexec/java_home)
> + fi
> +
> if [ -z "$JAVA_HOME" ] && [ -L /System/Library/Frameworks/JavaVM.framework/Versio
> #
> # Apple JDKs
> @@ -78,13 +85,6 @@ case "`uname`" in
> #
> export JAVA_HOME=/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home
> fi
> -
> - if [ -z "$JAVA_HOME" ] && [ -x "/usr/libexec/java_home" ]; then
> - #
> - # Apple JDKs
> - #
> - export JAVA_HOME=`/usr/libexec/java_home`
> - fi
> ;;
> esac
> there's another bug in the 3.2.5 release which appears to have been fixed in the current trunk: "export JAVA_HOME=/usr/libexec/java_home" was changed to "export JAVA_HOME=`/usr/libexec/java_home`" (with the back ticks). I prefer $() over ``, but it's irrelevant.
> I feel that /usr/libexec/java_home is the preferred method for finding the correct JAVA_HOME environment. Perhaps that is not correct.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)