Bugzilla – Full Text Bug Listing
| Summary: | java.home derives from Eclipse launch, not eclipse preferences | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | benson margulies <bimargulies> |
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | igor |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
Unlike Eclipse, Maven does not have the notion of "target JVM", so <systemPath>${java.home}/...</systemPath> really denotes a path relative to the jvm used to execute maven, which is eclipse vm in case of embedded maven runtime.
Igor, I understand and agree. The purpose of this JIRA was to write this all up including the common case where it causes trouble, primarily in the hopes of documentation. As per last comment, this is open for future reference, but WONTFIX otherwise. *** This bug has been marked as a duplicate of bug 432992 *** |
Build Identifier: 20110916-0149 In general, in Eclipse builds, the JRE used to launch eclipse itself is completely over-riden by the Java preferences dialog. This is not true for M2E, and deserves some prominent documentation -- since I doubt that there's a way to make it work differently. In particular, there's a very common POM idiom for using tools.jar: ${java.home}/../lib/tools.jar. This requires java.home to point to a JDK (well, the JRE inside of a JDK). By default, on Windows, people launching Eclipse end up launching it with a plain old JRE, and there's no tools.jar, and so Maven fails to find this dependency. The fix is to add -vm pathname/of/jdk/javaw.exe to config.ini. I can't see how M2E could make this problem go away, since java.home is controlled by the JVM itself, and trying to reset it to match the eclipse preference would be a recipe for other even more mysterious problems. Someone could, I suppose, try to write code to detect system dependency errors and warn of this, but I suspect that the best of the available alternatives is to write this up really clearly on the website and hope that people find it with Google. Reproducible: Always Steps to Reproduce: 1. import a project with a system dependency built off of ${java.home} 2. observe errors.