When a dog.barks()…

Struts 2 and Sun Micro’s tools.jar in Eclipse WTP
August 16, 2007, 3:05 am
Filed under: Java

A few days ago I setup my first Maven 2 enabled struts 2.0 WTP project. After an hour of muddling through the Eclipse IDE setup with WTP plus Maven, I soon ran into another trouble when I built the project in Eclipse. Maven told me that it missed the com.sun tools artifact that it couldn’t build the project.

Missing dependency tools.jar

8/13/07 5:58:51 PM CST: Missing:
1) com.sun:tools:jar:1.5.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun -DartifactId=tools \
-Dversion=1.5.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) tutorial:tutorial4:war:1.0-SNAPSHOT
2) org.apache.struts:struts2-core:jar:2.0.5
3) com.sun:tools:jar:1.5.0
1 required artifact is missing.
for artifact:
from the specified remote repositories:
central (http://repo1.maven.org/maven2)

Huh? It misses the tools.jar from Sun’s JDK.

Murders – Mr. profile “default-tools” & Mr. Sun Micro the JDK

I soon dig out that it is the struts2-core artifact has a dependency on Sun’s tools.jar. A profile named “default-tools.jar” declared the dependency on the tools.jar, which is activated when you are running the maven operation with Sun’s JDK. This is what you can see from struts2-core’s pom.

<value>Sun Microsystems Inc.</value>

Yet strange enough, I had no problem running the build with my command prompt. It only matters when running in Eclipse. To be exact, there was no problem when I manually triggered the building process by “Run as Maven2 Build” with the pom. But when Eclipse builds the project automatically, say after a clean, the error pops.

Adding the tools.jar to Eclipse’s JDK runtime does not help. Nonetheless this does look like a good practice so I give it up.

So what have went wrong? The profile try to look up the tools.jar by back stepping from the directory java.home, where it is the home directory of running Java process automatically deduced and set by Maven. If java.home points to a JDK, the path works as JDK comes with a tools.jar in the lib/ folder. But if java.home points to a JRE instead, the path should fail as JRE doesn’t bring along the tools.jar. When I start Eclipse, I could have started it by either a JRE or a JDK as I simply doubled clicked the shortcut to it on my desktop. The remaining problem is, isn’t it Eclipse is running the Maven 2 Builder with my configured JDK in the project? So I make the shots.

Starting Eclipse with -vm Option

The configuration free classic way to start Eclipse with desired VM.

$>eclipse -vm "C:\Program Files\Java\jdk1.6.0_01\bin"

Wow! It works. Okay, give it another shot.

Making JDK/bin the First Element in %PATH%

$>set PATH=C:\Program Files\Java\jdk1.6.0_01\bin;%PATH%

Jesus! it works again.


It looks like the when Eclipse is told to call the maven build manually with a pom.xml it, it executes with the configured JDK’s path. But when it comes to execute the Maven 2 Builder, it uses the Java process which starts the Eclipse instead. So if the Eclipse’s started with a Sun Micro JRE, it misses the tools.jar for struts2-core. Other JDK/JRE doesn’t matter, however, as the tools.jar or equivalent are usually on the classpath already.

Is it a behavior of Eclipse or just that of the M2Eclipse plug-in? I haven’t figured out yet. May be I just messed all the things up by accident (or luck). If anyone know what’s really inside, let me know 🙂


8 Comments so far
Leave a comment

I am having the same problem that you were having. I tried starting up eclipse (actually the myEclipse plugin) with the vm parameters changed to the jdk 1.6.0_02 bin folder but I still had errors regarding struts and tools.jar.
This is incredibly frustrating since as you say, it works if you run maven from the command line.
If you make any breakthroughs please let me know and I will do the same.

Comment by Cameron

Have you tried placing the JDK first in your %PATH% environment variable? You can verify if this trick works for you by the following simple test.

1. Open up a command prompt.
2. Execute the following commands. (Please change the JDK path to your own path and make sure there’s a tools.jar in the folder “lib”).

$>set PATH=C:\Program Files\Java\jdk1.6.0_01\bin;%PATH%

If this still does not work for you, try your luck with other JDK like JRockit from BEA.

Comment by Livingash

Thanks for your notes was very helpful.
I just want to point out that I tried your steps, but it didn’t working ad Livingash wrote. BUT …
I change the installed JRE inside Eclipse (Windows –> Preferences –> Java –> Installed JREs) to the JDK Home not the JRE.

This work for me even for the JDK 1.5.0.

This resolve an annoying problem that occurs for many month.

Thanks again

Comment by Marco

Thanks Macro. Nice to hear that you got the problem solved.

Actually our team has also tried changing the installed JDK from its default JRE to a JDK. It was the first attempt we took to try to solve the problem. But it didn’t work on any of our developer’s machine. Then I came up with the long investigation path I wrote in above.

I will try removing my trick and leave it alone the JDK configuration in Eclipse to see if the trick could have been simpler 🙂

Comment by Livingash

Your trick worked for me too.
But I think the main problem is caused by ${JAVA_HOME}/../lib/tools.jar
Eclipse started fine with JAVA_HOME=….\sun\jdk but maven failed to compile because it could not find ..\sun\lib\tools.jar
All is correct but is wrong ! 🙂
The file is in ..\sun\jdk\lib folder so why searches for it in the parent folder ?

After setting the -vm with ${JAVA_HOME}/bin correctly finds out the ../lib folder even if the default JDK of Eclipse points to ${JAVA_HOME} without the bin folder.

So, definitively something is wrong with setting that classpath.
Thanks to your trick I saved hours of searching through sources.

Comment by Viorel

Thanks for saving me from the misery!! I could have lost atleast another 8 hours..

Comment by Anjaneya

You’re welcome. I’m glad that this post this helps almost one and a half year after it is posted 🙂

Comment by Livingash

Nice catch dude, saved me some head scratching 🙂

Comment by Richard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: