[jira] [Comment Edited] (SUREFIRE-1923) Toolchain using JDK 6 does not work
[
https://issues.apache.org/jira/browse/SUREFIRE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370839#comment-17370839
]
Jarkko Rantavuori edited comment on SUREFIRE-1923 at 6/28/21, 8:44 PM:
---
Workaround is to disable forking. Then works also with 6.
{code:java}
0
{code}
However, with that I can't get for example coverage data with my build.
was (Author: jarkkor):
Workaround is to disable forking. Then works also with 6.
{code:java}
0
{code}
> Toolchain using JDK 6 does not work
> ---
>
> Key: SUREFIRE-1923
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1923
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jarkko Rantavuori
>Priority: Major
> Attachments: pom.xml
>
>
> Using toolchain in attempt to get a working build using Java 6, with Maven
> itself using Java 8. Shouldn't using the toolchain allow using older versions
> for compiling and execution of tests, since plugin itself is running with
> whatever Maven uses?
> Error I get is:
>
> {code:java}
> Error: Exception in thread "main" java.lang.UnsupportedClassVersionError:
> org/apache/maven/surefire/booter/ForkedBooter : Unsupported major.minor
> version 51.0
> Error:at java.lang.ClassLoader.defineClass1(Native Method)
> Error:at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
> Error:at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> Error:at java.net.URLClassLoader.defineClass(URLClassLoader.java:296)
> Error:at java.net.URLClassLoader.access$000(URLClassLoader.java:69)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:231)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
> Error:at java.security.AccessController.doPrivileged(Native Method)
> Error:at java.net.URLClassLoader.findClass(URLClassLoader.java:224)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
> Error:at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
> Error:at
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
> {code}
> Attached my pom.
> Also this error can be seen:
> {code:java}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project minimal-di: There are test failures.
> Error:
> Error: Please refer to
> /home/runner/work/minimal-di/minimal-di/target/surefire-reports for the
> individual test results.
> Error: Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> Error: The forked VM terminated without properly saying goodbye. VM
> crash or System.exit called?
> Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
> && /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
> -javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
> -jar
> /home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
> /home/runner/work/minimal-di/minimal-di/target/surefire
> 2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
> surefire_03168907528824382024tmp
> Error: Error occurred in starting fork, check output in log
> Error: Process Exit Code: 1
> Error: org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
> && /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
> -javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
> -jar
> /home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
> /home/runner/work/minimal-di/minimal-di/target/surefire
> 2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
> surefire_03168907528824382024tmp
> Error: Error occurred in starting fork, check output in log
> Error: Process Exit Code: 1
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:748)
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:305)
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:265)
> Error:at
> org.apache.
[jira] [Commented] (SUREFIRE-1923) Toolchain using JDK 6 does not work
[
https://issues.apache.org/jira/browse/SUREFIRE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370839#comment-17370839
]
Jarkko Rantavuori commented on SUREFIRE-1923:
-
Workaround is to disable forking. Then works also with 6.
{code:java}
0
{code}
> Toolchain using JDK 6 does not work
> ---
>
> Key: SUREFIRE-1923
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1923
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jarkko Rantavuori
>Priority: Major
> Attachments: pom.xml
>
>
> Using toolchain in attempt to get a working build using Java 6, with Maven
> itself using Java 8. Shouldn't using the toolchain allow using older versions
> for compiling and execution of tests, since plugin itself is running with
> whatever Maven uses?
> Error I get is:
>
> {code:java}
> Error: Exception in thread "main" java.lang.UnsupportedClassVersionError:
> org/apache/maven/surefire/booter/ForkedBooter : Unsupported major.minor
> version 51.0
> Error:at java.lang.ClassLoader.defineClass1(Native Method)
> Error:at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
> Error:at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> Error:at java.net.URLClassLoader.defineClass(URLClassLoader.java:296)
> Error:at java.net.URLClassLoader.access$000(URLClassLoader.java:69)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:231)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
> Error:at java.security.AccessController.doPrivileged(Native Method)
> Error:at java.net.URLClassLoader.findClass(URLClassLoader.java:224)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
> Error:at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
> Error:at
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
> {code}
> Attached my pom.
> Also this error can be seen:
> {code:java}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project minimal-di: There are test failures.
> Error:
> Error: Please refer to
> /home/runner/work/minimal-di/minimal-di/target/surefire-reports for the
> individual test results.
> Error: Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> Error: The forked VM terminated without properly saying goodbye. VM
> crash or System.exit called?
> Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
> && /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
> -javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
> -jar
> /home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
> /home/runner/work/minimal-di/minimal-di/target/surefire
> 2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
> surefire_03168907528824382024tmp
> Error: Error occurred in starting fork, check output in log
> Error: Process Exit Code: 1
> Error: org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
> && /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
> -javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
> -jar
> /home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
> /home/runner/work/minimal-di/minimal-di/target/surefire
> 2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
> surefire_03168907528824382024tmp
> Error: Error occurred in starting fork, check output in log
> Error: Process Exit Code: 1
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:748)
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:305)
> Error:at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:265)
> Error:at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> Error:at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
[jira] [Updated] (SUREFIRE-1923) Toolchain using JDK 6 does not work
[
https://issues.apache.org/jira/browse/SUREFIRE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated SUREFIRE-1923:
Description:
Using toolchain in attempt to get a working build using Java 6, with Maven
itself using Java 8. Shouldn't using the toolchain allow using older versions
for compiling and execution of tests, since plugin itself is running with
whatever Maven uses?
Error I get is:
{code:java}
Error: Exception in thread "main" java.lang.UnsupportedClassVersionError:
org/apache/maven/surefire/booter/ForkedBooter : Unsupported major.minor version
51.0
Error: at java.lang.ClassLoader.defineClass1(Native Method)
Error: at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
Error: at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
Error: at java.net.URLClassLoader.defineClass(URLClassLoader.java:296)
Error: at java.net.URLClassLoader.access$000(URLClassLoader.java:69)
Error: at java.net.URLClassLoader$1.run(URLClassLoader.java:231)
Error: at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
Error: at java.security.AccessController.doPrivileged(Native Method)
Error: at java.net.URLClassLoader.findClass(URLClassLoader.java:224)
Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
Error: at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
Error: at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
{code}
Attached my pom.
Also this error can be seen:
{code:java}
Error: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) on
project minimal-di: There are test failures.
Error:
Error: Please refer to
/home/runner/work/minimal-di/minimal-di/target/surefire-reports for the
individual test results.
Error: Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
Error: The forked VM terminated without properly saying goodbye. VM crash
or System.exit called?
Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
&& /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
-javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
-jar
/home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
/home/runner/work/minimal-di/minimal-di/target/surefire
2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
surefire_03168907528824382024tmp
Error: Error occurred in starting fork, check output in log
Error: Process Exit Code: 1
Error: org.apache.maven.surefire.booter.SurefireBooterForkException: The
forked VM terminated without properly saying goodbye. VM crash or System.exit
called?
Error: Command was /bin/sh -c cd /home/runner/work/minimal-di/minimal-di
&& /home/runner/.jabba/jdk/zulu@1.6.119/bin/java
-javaagent:/home/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/home/runner/work/minimal-di/minimal-di/target/jacoco.exec
-jar
/home/runner/work/minimal-di/minimal-di/target/surefire/surefirebooter4248000144598324679.jar
/home/runner/work/minimal-di/minimal-di/target/surefire
2021-06-28T18-08-47_748-jvmRun1 surefire5952048774464180572tmp
surefire_03168907528824382024tmp
Error: Error occurred in starting fork, check output in log
Error: Process Exit Code: 1
Error: at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:748)
Error: at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:305)
Error: at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:265)
Error: at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
Error: at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
Error: at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
Error: at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
Error: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
Error: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
Error: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
Error: at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
Error:
[jira] [Created] (SUREFIRE-1923) Toolchain using JDK 6 does not work
Jarkko Rantavuori created SUREFIRE-1923:
---
Summary: Toolchain using JDK 6 does not work
Key: SUREFIRE-1923
URL: https://issues.apache.org/jira/browse/SUREFIRE-1923
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M5
Reporter: Jarkko Rantavuori
Attachments: pom.xml
Using toolchain in attempt to get a working build using Java 6, with Maven
itself using Java 8. Shouldn't using the toolchain allow using older versions
for compiling and execution of tests, since plugin itself is running with
whatever Maven uses?
Error I get is:
{code:java}
Error: Exception in thread "main" java.lang.UnsupportedClassVersionError:
org/apache/maven/surefire/booter/ForkedBooter : Unsupported major.minor version
51.0
Error: at java.lang.ClassLoader.defineClass1(Native Method)
Error: at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
Error: at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
Error: at java.net.URLClassLoader.defineClass(URLClassLoader.java:296)
Error: at java.net.URLClassLoader.access$000(URLClassLoader.java:69)
Error: at java.net.URLClassLoader$1.run(URLClassLoader.java:231)
Error: at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
Error: at java.security.AccessController.doPrivileged(Native Method)
Error: at java.net.URLClassLoader.findClass(URLClassLoader.java:224)
Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
Error: at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
Error: at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
{code}
Attached my pom: [^pom.xml]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1923) Toolchain using JDK 6 does not work
[
https://issues.apache.org/jira/browse/SUREFIRE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated SUREFIRE-1923:
Attachment: pom.xml
> Toolchain using JDK 6 does not work
> ---
>
> Key: SUREFIRE-1923
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1923
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jarkko Rantavuori
>Priority: Major
> Attachments: pom.xml
>
>
> Using toolchain in attempt to get a working build using Java 6, with Maven
> itself using Java 8. Shouldn't using the toolchain allow using older versions
> for compiling and execution of tests, since plugin itself is running with
> whatever Maven uses?
> Error I get is:
>
> {code:java}
> Error: Exception in thread "main" java.lang.UnsupportedClassVersionError:
> org/apache/maven/surefire/booter/ForkedBooter : Unsupported major.minor
> version 51.0
> Error:at java.lang.ClassLoader.defineClass1(Native Method)
> Error:at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
> Error:at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> Error:at java.net.URLClassLoader.defineClass(URLClassLoader.java:296)
> Error:at java.net.URLClassLoader.access$000(URLClassLoader.java:69)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:231)
> Error:at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
> Error:at java.security.AccessController.doPrivileged(Native Method)
> Error:at java.net.URLClassLoader.findClass(URLClassLoader.java:224)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
> Error:at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:307)
> Error:at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
> Error:at
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:406)
> {code}
> Attached my pom: [^pom.xml]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ https://issues.apache.org/jira/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275889#comment-16275889 ] Jarkko Rantavuori edited comment on MASSEMBLY-360 at 12/3/17 11:49 AM: --- Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/ Relevant test case should be this one: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/it/projects/container-descriptors/metaInf-spring-aggregation/ However, it is not fixed. I forked an example project to demonstrate the issue:https://github.com/eis/assembly-plugin-spring-handler-testcase You can see that the build in master, using shade plugin, works. The build in assembly-plugin branch using assembly plugin does not: spring.handlers is not populated properly and application fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin version 2.2, and it was never fixed there as well: issue is the same. was (Author: jarkkor): Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/ (However relevant test case is no longer there.) However, it is not fixed. I forked an example project to demonstrate the issue:https://github.com/eis/assembly-plugin-spring-handler-testcase You can see that the build in master, using shade plugin, works. The build in assembly-plugin branch using assembly plugin does not: spring.handlers is not populated properly and application fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin version 2.2, and it was never fixed there as well: issue is the same. > When using mulitple Spring dependencies, the files from META-INF (from the > Spring jars) overwrite each other in an executable jar-with-dependencies. > > > Key: MASSEMBLY-360 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-360 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Windows XP, Java 5 >Reporter: Marielle Enderman >Assignee: John Casey > Fix For: 2.2 > > > I'm working on a Java 5 project with maven 2 and I need to deliver an > executable jar file. In this project I'm using different Spring dependencies: > >org.springframework > spring-beans > 2.5.5 > > > org.springframework > spring-context > 2.5.5 > > For maven packaging I'm using the maven-assembly plugin to create an > executable jar with dependencies (using the jar-with-dependencies > descriptor). Everything works fine, except that Spring's XSD files can't be > found. At least: not all of them. The fact is: Every Spring JAR file contains > a META-INF directory with files like spring.handlers and spring.schemas which > contain list of locations of respectively namespace handlers and schemas. > Unfortunately these files aren't merged during packaging so the META_INF of > the executable JAR file only contains the last one added. > This can result in errors like this: > Example 1: The spring-context-2.5.xsd can't be found: > WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored > XML validation warning org.xml.sax.SAXParseException: schema_reference.4: > Failed to read schema document > 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', > because 1) could not find the document; 2) the document could not be read; 3) > the root element of the document is not . > Example 2: The NamespaceHandler for the spring context namespace can't be > located: > Exception in thread "main" > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Unable to locate Spring NamespaceHandler for XML > schema namespace [http://www.springframework.org/schema/context] > When I manually merge the files, the executable JAR file works fine. > I hope this problem can be solved. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ https://issues.apache.org/jira/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275889#comment-16275889 ] Jarkko Rantavuori edited comment on MASSEMBLY-360 at 12/3/17 11:49 AM: --- Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/ Relevant test case should be this one: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/it/projects/container-descriptors/metaInf-spring-aggregation/ However, it is not fixed. I forked an example project to demonstrate the issue: https://github.com/eis/assembly-plugin-spring-handler-testcase You can see that the build in master, using shade plugin, works. The build in assembly-plugin branch using assembly plugin does not: spring.handlers is not populated properly and application fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin version 2.2, and it was never fixed there as well: issue is the same. was (Author: jarkkor): Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/ Relevant test case should be this one: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/it/projects/container-descriptors/metaInf-spring-aggregation/ However, it is not fixed. I forked an example project to demonstrate the issue:https://github.com/eis/assembly-plugin-spring-handler-testcase You can see that the build in master, using shade plugin, works. The build in assembly-plugin branch using assembly plugin does not: spring.handlers is not populated properly and application fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin version 2.2, and it was never fixed there as well: issue is the same. > When using mulitple Spring dependencies, the files from META-INF (from the > Spring jars) overwrite each other in an executable jar-with-dependencies. > > > Key: MASSEMBLY-360 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-360 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Windows XP, Java 5 >Reporter: Marielle Enderman >Assignee: John Casey > Fix For: 2.2 > > > I'm working on a Java 5 project with maven 2 and I need to deliver an > executable jar file. In this project I'm using different Spring dependencies: > >org.springframework > spring-beans > 2.5.5 > > > org.springframework > spring-context > 2.5.5 > > For maven packaging I'm using the maven-assembly plugin to create an > executable jar with dependencies (using the jar-with-dependencies > descriptor). Everything works fine, except that Spring's XSD files can't be > found. At least: not all of them. The fact is: Every Spring JAR file contains > a META-INF directory with files like spring.handlers and spring.schemas which > contain list of locations of respectively namespace handlers and schemas. > Unfortunately these files aren't merged during packaging so the META_INF of > the executable JAR file only contains the last one added. > This can result in errors like this: > Example 1: The spring-context-2.5.xsd can't be found: > WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored > XML validation warning org.xml.sax.SAXParseException: schema_reference.4: > Failed to read schema document > 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', > because 1) could not find the document; 2) the document could not be read; 3) > the root element of the document is not . > Example 2: The NamespaceHandler for the spring context namespace can't be > located: > Exception in thread "main" > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Unable to locate Spring NamespaceHandler for XML > schema namespace [http://www.springframework.org/schema/context] > When I manually merge the files, the executable JAR file works fine. > I hope this problem can be solved. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ https://issues.apache.org/jira/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275889#comment-16275889 ] Jarkko Rantavuori commented on MASSEMBLY-360: - Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/ (However relevant test case is no longer there.) However, it is not fixed. I forked an example project to demonstrate the issue:https://github.com/eis/assembly-plugin-spring-handler-testcase You can see that the build in master, using shade plugin, works. The build in assembly-plugin branch using assembly plugin does not: spring.handlers is not populated properly and application fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin version 2.2, and it was never fixed there as well: issue is the same. > When using mulitple Spring dependencies, the files from META-INF (from the > Spring jars) overwrite each other in an executable jar-with-dependencies. > > > Key: MASSEMBLY-360 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-360 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Windows XP, Java 5 >Reporter: Marielle Enderman >Assignee: John Casey > Fix For: 2.2 > > > I'm working on a Java 5 project with maven 2 and I need to deliver an > executable jar file. In this project I'm using different Spring dependencies: > >org.springframework > spring-beans > 2.5.5 > > > org.springframework > spring-context > 2.5.5 > > For maven packaging I'm using the maven-assembly plugin to create an > executable jar with dependencies (using the jar-with-dependencies > descriptor). Everything works fine, except that Spring's XSD files can't be > found. At least: not all of them. The fact is: Every Spring JAR file contains > a META-INF directory with files like spring.handlers and spring.schemas which > contain list of locations of respectively namespace handlers and schemas. > Unfortunately these files aren't merged during packaging so the META_INF of > the executable JAR file only contains the last one added. > This can result in errors like this: > Example 1: The spring-context-2.5.xsd can't be found: > WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored > XML validation warning org.xml.sax.SAXParseException: schema_reference.4: > Failed to read schema document > 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', > because 1) could not find the document; 2) the document could not be read; 3) > the root element of the document is not . > Example 2: The NamespaceHandler for the spring context namespace can't be > located: > Exception in thread "main" > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Unable to locate Spring NamespaceHandler for XML > schema namespace [http://www.springframework.org/schema/context] > When I manually merge the files, the executable JAR file works fine. > I hope this problem can be solved. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069249#comment-15069249
]
Jarkko Rantavuori commented on MNG-5756:
I can provide a patch/PR if that's what's needed. I guess this is too trivial
to interest people in participation, but in SO there's already been ~20 votes
about the subject.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068974#comment-15068974
]
Jarkko Rantavuori commented on MNG-5756:
Surely this isn't close-pending due to that? Java 9 GA is currently scheduled
for March 2017, and has already been delayed. It's hardly a reason to not fix
this now. Even when it hits GA this will continue to be a problem in earlier
versions.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
> Labels: close-pending
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948935#comment-14948935
]
Jarkko Rantavuori edited comment on MNG-5756 at 10/8/15 4:24 PM:
-
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I don't agree on the correctness. Maven shouldn't be saying things about
"java home" or "Java home" when it is actually referring to "java.home". I
don't think you disagree about the statement that normally when anybody in java
ecosystem is talking about java home, they refer to JAVA_HOME environment
setting. Given that, if output of a program is meaning something else with it,
it would be the fault of that program - in this case Maven. This has been
evident with tens of users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Agreed. And {{java.home}} != {{java home}}. But "java home", if that term is to
be used, really should refer to JAVA_HOME.
was (Author: jarkkor):
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Agreed. And {{java.home}} != {{java home}}. But "java home", if that term is to
be used, really should refer to JAVA_HOME.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948935#comment-14948935
]
Jarkko Rantavuori edited comment on MNG-5756 at 10/8/15 4:23 PM:
-
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Agreed. And {{java.home}} != {{java home}}. But "java home", if that term is to
be used, really should refer to JAVA_HOME.
was (Author: jarkkor):
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Yes. And {{java.home}} != {{java home}}. But "java home", if that term is to be
used, really should refer to JAVA_HOME.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948935#comment-14948935
]
Jarkko Rantavuori edited comment on MNG-5756 at 10/8/15 4:23 PM:
-
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Yes. And {{java.home}} != {{java home}}. But "java home", if that term is to be
used, really should refer to JAVA_HOME.
was (Author: jarkkor):
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Yes. And {noformat}java.home{noformat} != {noformat}java home{noformat}. But
"java home", if that term is to be used, really should refer to JAVA_HOME.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948935#comment-14948935
]
Jarkko Rantavuori commented on MNG-5756:
{quote}System.getProperty( "java.home", "" ) this is
correct. Though it is confusing.{quote}
Well, I just don't agree. Maven shouldn't be saying things about "java home" or
"Java home" when it is actually referring to "java.home". I don't think you
disagree about the statement that normally when anybody in java ecosystem is
talking about java home, they refer to JAVA_HOME environment setting. Given
that, if output of a program is meaning something else with it, it would be the
fault of that program - in this case Maven. This has been evident with tens of
users tripping on this on stackoverflow.
{quote}JAVA_HOME != java.home.{quote}
Yes. And {noformat}java.home{noformat} != {noformat}java home{noformat}. But
"java home", if that term is to be used, really should refer to JAVA_HOME.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> J
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948089#comment-14948089
]
Jarkko Rantavuori commented on MNG-5756:
Agreed. But it is Maven talking about "Java home", and it is maven doing
{noformat}System.getProperty( "java.home", "" ) {noformat}
instead of
{noformat}System.getenv("JAVA_HOME"){noformat}
when describing it.
Your suggestion sounds good to me. There might be some confusion if some user
thinks "JRE home" is something one should set in the environment, like
JAVA_HOME, so personally I would maybe say something like
{noformat}
Java home: .../java8
JRE used: .../java8/jre
{noformat}
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947563#comment-14947563
]
Jarkko Rantavuori commented on MNG-5756:
It does matter, when users constantly confuse it with JAVA_HOME (like I pointed
out in stackoverflow threads. there are others as well). JAVA_HOME is the thing
everybody knows and can set directly, so when Maven output is talking about
"Java home", it is understandable that users get confused. In common language,
JAVA_HOME is indeed the thing everybody in java world means when talking about
java home. Furthermore, Maven startup scripts use JAVA_HOME to look up which
java they use for running Maven, so it is actually the relevant piece of
information when configuring Maven. I can't imagine a reason why mvn -v output
would show jre used for running.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Affects Version/s: 3.3.3
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://jira.codehaus.org/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program
[jira] (MNG-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://jira.codehaus.org/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Pr
[jira] (MNG-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
`Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre`
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://jira.codehaus.org/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Progr
[jira] (MNG-5756) Java home output in mvn -v is misleading
Jarkko Rantavuori created MNG-5756:
--
Summary: Java home output in mvn -v is misleading
Key: MNG-5756
URL: https://jira.codehaus.org/browse/MNG-5756
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Environment: any
Reporter: Jarkko Rantavuori
Priority: Minor
For example on my windows box, mvn -v prints the following:
`Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre`
But my JAVA_HOME is actually
{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home",
"" ) ).append( ls );
{code}
which is using property "java.home" to fetch java home. However, "java.home"
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME").
Either that should be used or current output should be changed so it wouldn't
be so misleading.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
