[jira] (MPIR-329) French translation in project-info-report_fr.properties
[ https://jira.codehaus.org/browse/MPIR-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361298#comment-361298 ] Olivier Maury commented on MPIR-329: I never tried myself the narrow no-break space, however I never saw it in translation. > French translation in project-info-report_fr.properties > --- > > Key: MPIR-329 > URL: https://jira.codehaus.org/browse/MPIR-329 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Olivier Maury >Priority: Minor > Attachments: project-info-report_fr.properties, > project-info-report_fr.properties.patch > > > Some corrections on typography and term. > File from > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_fr.properties -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-329) French translation in project-info-report_fr.properties
[ https://jira.codehaus.org/browse/MPIR-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361298#comment-361298 ] Olivier Maury edited comment on MPIR-329 at 1/17/15 7:12 AM: - I never tried myself the narrow no-break space, however I never saw it in translation. I've only read the usual no-break space ([nbsp] at Launchpad, in HTML ...). was (Author: olivier-maury): I never tried myself the narrow no-break space, however I never saw it in translation. > French translation in project-info-report_fr.properties > --- > > Key: MPIR-329 > URL: https://jira.codehaus.org/browse/MPIR-329 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Olivier Maury >Priority: Minor > Attachments: project-info-report_fr.properties, > project-info-report_fr.properties.patch > > > Some corrections on typography and term. > File from > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_fr.properties -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-329) French translation in project-info-report_fr.properties
[ https://jira.codehaus.org/browse/MPIR-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361301#comment-361301 ] Michael Osipov commented on MPIR-329: - Have a look here: http://www.fileformat.info/info/unicode/char/202f/browsertest.htm Works great with FF 35. Please give it a try and update the patch according if you think fit. I will commit it then. > French translation in project-info-report_fr.properties > --- > > Key: MPIR-329 > URL: https://jira.codehaus.org/browse/MPIR-329 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Olivier Maury >Priority: Minor > Attachments: project-info-report_fr.properties, > project-info-report_fr.properties.patch > > > Some corrections on typography and term. > File from > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_fr.properties -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5754) Toolchains should be read during initialization
[
https://jira.codehaus.org/browse/MNG-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5754.
---
Resolution: Fixed
Fix Version/s: 3.2.6
Fixed in
[f75008743b2c0fa19ca83c46535c24bb5e2c9215|http://git-wip-us.apache.org/repos/asf/maven/commit/f7500874]
and
[b6ae8ef8abfa16f03dcf3d0bf9697be64da138fe|http://git-wip-us.apache.org/repos/asf/maven/commit/b6ae8ef8]
> Toolchains should be read during initialization
> ---
>
> Key: MNG-5754
> URL: https://jira.codehaus.org/browse/MNG-5754
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Affects Versions: 3.2.5
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2.6
>
>
> Right now the reading of toolchains is triggered by the
> {{maven-toolchains-plugin}}. This is not efficient, since the same files will
> be read over and over again in a multimodule project. This might be even be
> more tricky when building with multiple threads.
> We probably can assume that if someone has specified a {{toolchains.xml}}, he
> also wants to use it. I don't see any reason why to wait until the first the
> {{maven-toolchains-plugin}} is called.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-276) remove RedundantThrows rule from default configs
Herve Boutemy created MCHECKSTYLE-276: - Summary: remove RedundantThrows rule from default configs Key: MCHECKSTYLE-276 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-276 Project: Maven Checkstyle Plugin Issue Type: Task Components: predefined ruleset: Maven , predefined ruleset: Sun Affects Versions: 2.13 Reporter: Herve Boutemy it causes false positives and is removed in Checkstyle 6.x: having this rule in predefined configurations makes it hard to upgrade Checkstyle version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-276) remove RedundantThrows rule from default configs
[ https://jira.codehaus.org/browse/MCHECKSTYLE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MCHECKSTYLE-276. - Resolution: Fixed Fix Version/s: 2.14 Assignee: Herve Boutemy done in [r1652642|http://svn.apache.org/r1652642] > remove RedundantThrows rule from default configs > > > Key: MCHECKSTYLE-276 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-276 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: predefined ruleset: Maven , predefined ruleset: Sun >Affects Versions: 2.13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.14 > > > it causes false positives and is removed in Checkstyle 6.x: having this rule > in predefined configurations makes it hard to upgrade Checkstyle version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MCHECKSTYLE-163:
--
Description:
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included to
resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from request.getProject().getTestClasspathElements()
(see DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as test are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
test dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
{code:xml}
junit
junit
${junit.version}
test
{code}
Throw any junit exception within project test code, e.g.:
{code:java}public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class klass) throws
InitializationError {
{code}
If RedundantThrows check is enabled, the following error will be thrown:
{noformat}[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check
(checkstyle-verify) @ sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.{noformat}
was:
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included to
resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from request.getProject().getTestClasspathElements()
(see DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as test are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
test dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
junit
junit
${junit.version}
test
Throw any junit exception within project test code, e.g.:
public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class klass) throws
InitializationError {
If RedundantThrows check is enabled, the following error will be thrown:
[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Chris Whelan
>Assignee: Olivier Lamy
> Fix For: 2.7
>
> Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
>
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @req
[jira] (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361305#comment-361305
]
Herve Boutemy commented on MCHECKSTYLE-163:
---
RedundantThrows rule seems buggy and is removed in recent Checkstyle versions
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Chris Whelan
>Assignee: Olivier Lamy
> Fix For: 2.7
>
> Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
>
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @requiresDependencyResolution compile which means that pom dependencies which
> have been declared as test are not returned by
> project.getTestClasspathElements().
> This is a particular issue for the checkstyle RedundantThrows check
> (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
> requires all Exceptions to be available on it's classpath.
> If code throws an Exception which has been imported from a maven
> test dependency, the exception will not be available on the
> classpath and this checkstyle check will fail.
> Example:
> Include junit as a test scope dependency in the project POM:
> {code:xml}
> junit
> junit
> ${junit.version}
> test
> {code}
> Throw any junit exception within project test code, e.g.:
> {code:java}public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
> public MyCustomTestRunner(final Class klass) throws
> InitializationError {
> {code}
> If RedundantThrows check is enabled, the following error will be thrown:
> {noformat}[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check
> (checkstyle-verify) @ sample-project ---
> [INFO] Starting audit...
> C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
> warning: Unable to get class information for InitializationError.
> Audit done.
> [ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
> InitializationError.{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-276) remove RedundantThrows rule from default configs
[ https://jira.codehaus.org/browse/MCHECKSTYLE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MCHECKSTYLE-276: -- Description: it causes false positives and is removed in Checkstyle 6.x: see https://github.com/checkstyle/checkstyle/issues/473 Having this rule in predefined configurations makes it hard to upgrade Checkstyle version was:it causes false positives and is removed in Checkstyle 6.x: having this rule in predefined configurations makes it hard to upgrade Checkstyle version > remove RedundantThrows rule from default configs > > > Key: MCHECKSTYLE-276 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-276 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: predefined ruleset: Maven , predefined ruleset: Sun >Affects Versions: 2.13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.14 > > > it causes false positives and is removed in Checkstyle 6.x: see > https://github.com/checkstyle/checkstyle/issues/473 > Having this rule in predefined configurations makes it hard to upgrade > Checkstyle version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-276) remove RedundantThrows rule from default configs
[ https://jira.codehaus.org/browse/MCHECKSTYLE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MCHECKSTYLE-276: -- Description: it causes false positives and is removed in Checkstyle 6.2: see https://github.com/checkstyle/checkstyle/issues/473 Having this rule in predefined configurations makes it hard to upgrade Checkstyle version was: it causes false positives and is removed in Checkstyle 6.x: see https://github.com/checkstyle/checkstyle/issues/473 Having this rule in predefined configurations makes it hard to upgrade Checkstyle version > remove RedundantThrows rule from default configs > > > Key: MCHECKSTYLE-276 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-276 > Project: Maven Checkstyle Plugin > Issue Type: Task > Components: predefined ruleset: Maven , predefined ruleset: Sun >Affects Versions: 2.13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.14 > > > it causes false positives and is removed in Checkstyle 6.2: see > https://github.com/checkstyle/checkstyle/issues/473 > Having this rule in predefined configurations makes it hard to upgrade > Checkstyle version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDF-71) Remove backward compatibility with Maven 2.0.X
[ https://jira.codehaus.org/browse/MPDF-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MPDF-71: Fix Version/s: 1.3 > Remove backward compatibility with Maven 2.0.X > -- > > Key: MPDF-71 > URL: https://jira.codehaus.org/browse/MPDF-71 > Project: Maven PDF Plugin > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.3 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDF-71) Remove backward compatibility with Maven 2.0.X
Karl-Heinz Marbaise created MPDF-71: --- Summary: Remove backward compatibility with Maven 2.0.X Key: MPDF-71 URL: https://jira.codehaus.org/browse/MPDF-71 Project: Maven PDF Plugin Issue Type: Improvement Affects Versions: 1.3 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDF-71) Remove backward compatibility with Maven 2.0.X
[ https://jira.codehaus.org/browse/MPDF-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MPDF-71. --- Resolution: Fixed Fixed in [r1652654|http://svn.apache.org/r1652654] > Remove backward compatibility with Maven 2.0.X > -- > > Key: MPDF-71 > URL: https://jira.codehaus.org/browse/MPDF-71 > Project: Maven PDF Plugin > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.3 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDF-71) Remove backward compatibility with Maven 2.0.X
[ https://jira.codehaus.org/browse/MPDF-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reassigned MPDF-71: --- Assignee: Karl-Heinz Marbaise > Remove backward compatibility with Maven 2.0.X > -- > > Key: MPDF-71 > URL: https://jira.codehaus.org/browse/MPDF-71 > Project: Maven PDF Plugin > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.3 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361310#comment-361310
]
Scott Carey commented on MNG-5686:
--
This issue is marked as Closed, fixed for 3.2.5, but mvn 3.2.5 still has this
issue for me.
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Kristian Rosenvold
> Fix For: 3.2.5
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Takayoshi Fujiki reopened MNG-5686:
---
Let me Reopen this issue, because 3.2.5 still has this issue for me too.
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Kristian Rosenvold
> Fix For: 3.2.5
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
