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)