Closed bonifaido closed 10 years ago
I think thus has to do with your IDE (or environment) using a JRE instead of a JDK for running maven. I don't like the idea of adding a dependency on a specific tools.jar version or a specific directory structure that finds it on some systems, as that won't be portable; neither to other OSs or even to MacOS that doesn't have a 1.6.0 Java JDK installed somewhere.
I'm running maven with JDK 7. This official maven page helped me to resolve the issue. Actually the version number in the dependency section is very relaxed in this case because it directly points to the exact jar file instead of using the resolution mechanism.
After reading this Java 7 article I found the following:
The tools classes in tools.jar are only used to run javac and javadoc. The tools classes are not used to resolve source code references unless tools.jar is in the user class path.
May I ask you which JDK are you using, Oracle or OpenJDK? Maybe this makes a difference.
The page you refer to does show how to add a tools.jar dependency, but while that may work to resolving a private system issue, I doubt that it's portable (and wouldn't want to have to test all the various platforms). The expectation is that you use a JDK (and not a JRE) to build things, and I don't think tools. jar will be missing if you have a JDK as yu JAVA_HOME.
On my Mac, I use Java 6 and Java 7 JDKs, downloaded from the Oraclehttp://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
I use Java 6 to build jHiccup to make sure it doesn't rely on Java 7 things, but the same should work with Java 7 JDKs, obviously.
% env | grep JAVA_HOME JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
% java -version java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
Maven works from the command line with this. And from IntelliJ.
You're right, adding something like this to the pom doesn't sound like a good idea. However I have tried to build with JDK 6 and it works as it should:
export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0_51-b11-457.jdk/Contents/Home
mvn clean package
When I change to JDK 7
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
mvn clean package
somehow tools.jar disappears from the classpath and I get the compile errors.
Ok. I see the same problem with 1.7.0_45 on my Mac. As ugly as it is, I guess maven won't be pacified without the dependency (no good way to add tools.jar to the compilation class path without it). To make sure this effects only for the compilation, and not in the packaging, I've merged the pull request, and added the following:
[Note: The version number is irrelevant for how a system path dependency is located, and appears to only affect how the result is copied into the target directory. Since We're excluding the tools.jar from actually being copied to the target directory, the version number is meaningless (but still required syntactically). To make sure people don't confuse it with something else, I'm numbering it with 99.9 instead of 1.6]
On Mac OS X 10.9 with java 1.7.0_45 I couldn't get it compiled without adding the tools.jar as an explicit dependency.