[
https://jira.codehaus.org/browse/MNG-5759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cory Steers updated MNG-5759:
-----------------------------
Complexity: Novice (was: Intermediate)
Description:
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.
was:
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:
> 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)
