14

From my searching, I found supporting information here: Java Development Guide for Mac OS X

tools.jar does not exist. Classes usually located here are instead included in classes.jar. Scripts that rely on the existence of tools.jar need to be rewritten accordingly.

If a rewrite is inevitable, how does that go?

This problem was encountered while deploying on Tomcat 6 installed via MacPorts on a Mac OS X 10.6 machine.

Nikki Erwin Ramirez
  • 9,676
  • 6
  • 30
  • 32
  • Erwin Ramizer: a few notes... The way Java works on OS X will change soon with the new OS X release, which shall not install Java by default. Soon Apple won't be shipping Java anymore on OS X and it's likely the new "shipper" will not be packaging Java in the same way. OS X "server" and Mac servers are apparently getting discontinued :( – SyntaxT3rr0r Apr 11 '11 at 09:09
  • Does that mean Java developers will then have free rein on their dev environments? By that, I mean installing the "official" packages would be the norm (like in Linux distros), instead of relying on the pre-packaged JDK/JRE. If so, then Java dev environments would look more similar regardless of the platform, right (which, I suppose, is a good thing)? – Nikki Erwin Ramirez Apr 11 '11 at 12:09
  • I have no idea... I'm waiting to see how things turn out too :) – SyntaxT3rr0r Apr 11 '11 at 12:15
  • Now I don't know how to close this question. As it turns out, the guy who asked me this no longer experiences the problem. I asked him how it got resolved, and I haven't received a response yet. – Nikki Erwin Ramirez Apr 12 '11 at 05:58

7 Answers7

8

Here is my tested solution, which implies no change in maven config, just add symbolic links:

  • ln -s /Library/Java/JavaVirtualMachines/1.6.0_38-b04-436.jdk/Contents/Home/../Classes/classes.jar /Library/Java/JavaVirtualMachines/1.6.0_38-b04-436.jdk/Contents/Home/../Classes/tools.jar
  • ln -s /Library/Java/JavaVirtualMachines/1.6.0_38-b04-436.jdk/Contents/Home/../Classes /Library/Java/JavaVirtualMachines/1.6.0_38-b04-436.jdk/Contents/Home/../lib

Enjoy! Bruno

Bruno Jullien
  • 91
  • 1
  • 2
  • Quick note, I had to change my JAVA_HOME to point to the /Library/Java/JavaVirtualMachines/1.6.0_38-b04-436.jdk/Contents/Home/ because by default on my mountain lion machine it was pointing to /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home – Chris Hinshaw Jun 03 '13 at 17:36
  • 1
    In my case: `sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/Classes ` and `sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/Classes/classes.jar` – frapen Nov 21 '16 at 20:33
4

This is similar to Bruno's answer above; however, I am not a big fan of symlinking the absolute path. Here is how I handle the symlinks:

cd /Library/Java/JavaVirtualMachines/<jdk version>/Contents/Home
sudo ln -s lib Classes

cd lib/
sudo ln -s tools.jar classes.jar

That makes it easier then symlinking absolute paths.

Ray Hunter
  • 15,137
  • 5
  • 53
  • 51
1

Well, you search for 'tools.jar', with grep for instance. If the place where classes.jar is, where tools.jar was expected, you could just change the word.

Another idea is, to create a symbolic link from classes.jar to tools.jar, if you have enough privileges and the file system(s) on MacOS support this. Else: copy. Might be more easy, but not be forgotten for updates, maybe.

user unknown
  • 35,537
  • 11
  • 75
  • 121
1

Instead of using Tomcat from Macports download Tomcat from Apache.

6.0: http://tomcat.apache.org/download-60.cgi

7.0: http://tomcat.apache.org/download-70.cgi

sourcedelica
  • 23,940
  • 7
  • 66
  • 74
  • I was avoiding having to install from source, which was why I chose MacPorts. Now, I don't remember why I decided that way. Probably because some other software was already installed via MacPorts, so I might have thought to maximize its use. – Nikki Erwin Ramirez Apr 12 '11 at 05:56
  • You don't have to install from source, you can download one of the binary distributions from the links above. Just unzip and you're done. – sourcedelica Apr 12 '11 at 12:27
0

Edit to Bruno's answer which was finally what worked for me after quite a bit of maven trial and error.

If you are using 1.7 then you should be able to change revision to 1.7. I do not know if this is still a problem in Java 1.7 though.

sudo sh -c '$(j_home=$(/usr/libexec/java_home -v 1.6) && ln -sf ${j_home}/../Classes/classes.jar ${j_home}/../Classes/tools.jar && ln -sf ${j_home}/../Classes ${j_home}/../lib)'
Chris Hinshaw
  • 6,967
  • 2
  • 39
  • 65
0

I faced the same problem, and resolved it differently.

  • First check that the java_home is set as /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents and not /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
  • Add the cobertura plugin, make sure systemPath is correctly ref the location of classes.jar

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.6</version>
            <dependencies>
                <dependency>
                    <groupId>com.sun</groupId>
                    <artifactId>tools</artifactId>
                    <version>1.6</version>
                    <scope>system</scope>
                    <systemPath>${java_home}/Classes/classes.jar</systemPath>
                </dependency>
            </dependencies>
        </plugin>
    
  • Add the dependency and exclude tools

        <dependency>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
        <version>2.6</version>
        <scope>test</scope>
        <exclusions>
            <exclusion>
                <groupId>com.sun</groupId>
                <artifactId>tools</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    
  • Finally add the following profiles

    <profiles>
    <profile>
        <id>standard-jdk</id>
        <activation>
            <file>
                <exists>${java_home}/Home/lib/tools.jar</exists>
            </file>
        </activation>
        <properties>
            <tools-jar>${java_home}/Home/lib/tools.jar</tools-jar>
        </properties>
    </profile>
    <profile>
        <id>apple-jdk</id>
        <activation>
            <file>
                <exists>${java_home}/Classes/classes.jar</exists>
            </file>
        </activation>
        <properties>
            <tools-jar>${java_home}/Classes/classes.jar</tools-jar>
        </properties>
    </profile>
    

Now run maven and it should successfully generate the Cobertura reports!

tintin
  • 5,676
  • 15
  • 68
  • 97
0

Can't find any references to it on the interweb, but my Mac 1.7 and 1.8 jdk's now have tools.jar.

/Library/Java/JavaVirtualMachines/jdk1.7.0_12.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/tools.jar /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar

classes.jar is only present in mac 1.6 jdk.

--Erik