Develop Reference

Intellij recognizes maven dependency as SNAPSHOT

I am using Intellij IDEA 2021.3.1 Community edition on Linux for one of my Maven project. In the pom.xml file, there is a dependency with system scope having version 3.0-20211116.183306-362 as mentioned below:
<dependency>
<groupId>com.wd.xml</groupId>
<artifactId>wdXml</artifactId>
<scope>system</scope>
<systemPath>/home/mylib/wdXml-3.0-20211116.183306-362.jar</systemPath>
<version>3.0-20211116.183306-362</version>
</dependency>
The pom.xml does not have any issue, and mvn package command runs fine. However, the editor shows compilation errors in the Java class using this dependency.
Upon hours of digging, I found that in the 'Project Dependencies View' Intellij lists this dependency as com.wd.xml:wdXml:3.0-SNAPSHOT instead of com.wd.xml:wdXml:3.0-20211116.183306-362.
UPDATE
I believe it is because of this Maven convention
version if you distribute it, then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look. For example,
2.0, 2.0.1, 1.3.1
How do I resolve this? Is there any setting in the IDE that can be tweaked.

Eclipse is confused by imports ("accessible from more than one module")

When referencing simple .jar files, Eclipse shows an error stating:
The package java.awt is accessible from more than one module: <unnamed>, java.desktop
This happens for instance when javax.awt or javax.swing is included in the .jar files.
The simplest example would be the following:
package test;
import javax.swing.JDialog;
public class Test {
public static void main(String[] args) {
new JDialog();
}
}
Adding a .jar file to the classpath with only the folder structure javax/swing (no files needed) will cause the error to appear. I'm using JDK 10/12 (neither works). Setting the compiler compliance to 1.8 makes the whole thing work again.
On another machine with Eclipse 2018-09 this works with compiler compliance set to 10.
I'm on Eclipse 2019-03, on a (for testing purposes) freshly installed Eclipse 2018-09 it works fine. Why?
Edit June/2020 (Solution)
As the answers correctly stated, this is a restriction built into Java ages ago and only recently was forced upon us. I came into contact with it while migrating a big project with dozens of dependencies to Maven. There were libraries from around the year 2000! There were 'meta libraries' which consisted of several libraries packaged together.
So there was no other way than to identify what was still needed (into the trash with the rest!), update libraries which violate the rules or find replacements for them. This took me many, many hours.
In the end it worked out and we've got a nice Maven project to work with.

This is caused by
a JAR on the Classpath that contains the package java.awt that also exists in the system library but the
JRE System Library is on the Modulepath
In the Java Platform Module System (JPMS) it is not allowed to use the same package in more than one module. If the Modulepath and the Classpath is used, everything on the Classpath is handled as the <unnamed> module (in your case the package java.awt exists in the system module java.desktop and also via the JAR on the Classpath in the module <unnamed>).
Since the JRE System Library cannot be moved from the Modulepath to the Classpath (see this answer by Stephan Herrmann for details), you only have the following options:
Set the compiler compliance to 1.8 (as you already mentioned)
Rebuilt the JAR to avoid Java system library package names inside the JAR (if reflection is used, additional code changes may be necessary):
If you have the source code, change the package names (e.g. change the package and subpackae java to java_util and javax to javax_util) and recreate the JAR
If you have only the .class files you have to decompile the .class files first

Since I'll bet lots of people will be running into this problem with modular Java, I'll help and give the real answer.
This error happens when
you have a dependency in your project
that contains code
using packages
that are also in the modules
being referenced by your project
If your project has set the source compatibility to something like Java 12, it will start enforcing the rule, that has been there all along in Java:
"Don't use packages that belong to the JDK in your own code."
Unfortunately, lots of developers and vendors have done that over the years. Can't do that anymore.
If you set your project to Java 12 source compatibility, Eclipse adds the JDK modules which include everything "java.*" and "javax.*" and even "jdk.*", "org.w3c.*". These packages may be in use by your dependencies or their transitive dependencies.
How to fix
You need to:
look at which package its complaining about
and expand the "Projects and External Dependencies" node in the Package Explorer.
Find out which dependency is using that package.
Then you can simply exclude that dependency from your project.
Or you could get the source of that dependency, if available, and rebuild the jar with changed packages. Otherwise you have to remove that dependency and find a replacement for that technology. Pain huh?
If its a transitive dependency you can often just exclude it. Here is an example of that for Gradle based projects.
GradleConfig.xml:
configurations {
all*.exclude group: 'xml-apis'
}

In my case, it was because I included a dependency (Apache Tika) in the POM.xml file.
I had to force the exclusion of the module that contained the classes with errors while imported at that dependency:
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24.1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
It worked for me that way.

I found a simple solution to troubleshoot this in Eclipse. Hit Ctrl + Shift + T in Eclipse to open the Open Type prompt. Then type the name of the package that is causing the issue. For me, it was org.w3c.dom. Now the search results will show all the locations from where this package is being loaded. Remove every JAR from the classpath that comes in the result other than the JDK 11 library.
My project being a legacy one, I had to remove a lot of JARs from the build path. Also, my project does not use Maven. So removing the JARs was a fairly straightforward step. The steps might vary for other build tools like ANT, Maven, Gradle, etc. I have just explained the troubleshooting steps above.

See also: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml where I answered:
Disappointingly I don't see any compiler flags to show what jar the problem is with
Even -Xlint:module doesn't seem to show up anything useful and eclipse doesn't shed any light on the issue
Instead to find where java.awt comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q java.awt; then echo $i; fi ; done
Strictly you don't have to specify the scope test as that's the default but I've included it as you might want to use compile instead

I think my flavour of the problem might be useful.
I got this error for classes under javax.xml.stream, by old Maven projects that depend on artifacts like xml-apis, stax-api, or geronimo-stax-api.
Technically, the problem is what others have already said: those artifacts expose the javax.xml.* package without any awareness of Java modules (they were invented later), so the package is automatically assigned to the unnamed module, which conflicts with the same package being included in the JDK's most recent versions, where the package has its own module name, and therefore the same package results in two different modules, which is forbidden.
That said, the practical solution is essentially to work with Maven exclusions to remove those dependencies from your project and let it use the JDK version instead (or, of course, remove them as direct dependencies, if that's your case). Use the equivalent if you're working with another build system.
In theory, the more recent flavours of these packages offered by the JDK might be non backward-compatible, in practice, I doubt such JSR specifications changed much over the years and so far, I haven't seen any issue with their replacement.

Since this is ranks quite high on Google I'm going to drop this here in case it's helpful for someone.
I've found some interesting behaviour with Java 11 and the xmlbeans library. The xmlbeans library is a transitive dependency of Apache POI, a very popular library for working with Microsoft Office documents, it is used to handle the internal XML structures of the newer Office formats. I've tested it with Apache POI 3.9 and it works perfectly fine, despite the error shown by Eclipse. So, I guess in Java 11 this rule it's not fully enforced.

For Apache POI version 5.0.0 using Maven, in the pom.xml:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>5.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.0.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Fixed: "The package javax.xml.parsers is accessible from more than one module"

I met a similar issue with the eclipse IDE while upgrading JDK from 1.8 to 11, "The package org.w3c.dom is accessible from more than one module: , java.xml". upgrading eclipse from 2019 to 2021 and setting system JDK home to 11 does not solve it. I don't think it's caused by "org.w3c.dom" existing in different jars of the classpath,dut to "Order and Export" should ordered the search sequence.
After several hours of searching and investigating, this issue is fixed by setting the Java Compiler - Compiler compliance level to 1.8(default is 11).

You can do what other people suggest which is to exclude xml-apis which worked fine with me, but if your are using and an old jaxb-api replace them with jakarta.xml.bind-api:
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.3</version>
</dependency>
and of course upgrade your jaxb-impl to match the same api:
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.3</version>
</dependency>

Steps below helped me,
Right click Eclipse project > Properties > Java Build Path
In Libraries tab, remove all the external jar files under Modulepath and add them under Classpath (you can just select all the jars and drag them under Classpath)
Click Apply and Close
Hope it help you too.

Wow, this was a tough one!
Some helpful tips (a summary of my journey through this maze):
This started when I migrated from Java 1.8 to 11.0.11
Right out of the gate this caused problems. I needed to change the syntax for how to specify the Java version for the maven build plug in as shown below:
Before
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
After
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
After that, everything compiled at a command prompt. However, when opening the project in Eclipse, I got a bunch of errors as shown in the next section.
Getting "<class> cannot be resolved to a type" errors
When I got errors in Eclipse and not at the command line I immediately started looking at configuration settings in Eclipse to no avail. After some googling I came to this post. The post at https://www.eclipse.org/forums/index.php/t/1110036/ was also very helpful.
Finding what resources were the problem
The answer to this post by #Anu suggesting using <shift><ctrl>T to bring up the type search window was very helpful using this I was able to see what resources were causing the problem (i.e. any resource that is also included in the JDK, in my case it was the ErrorHandler in the xml-apis jar). Type the name of one of the resources giving a "cannot be resolved to type" to see the name of the jar file, in my case the jar is xml-apis-1.4.01.jar.
All of this is shown in the screen shot below (click on the image to get a cleaner view).
Finding the Dependency that contains the offending jar
We can now use the information from https://www.eclipse.org/forums/index.php/t/1110036/ to find the dependency in our pom.xml file that contains the offending resource.
Open the pom.xml file in Eclipse and select the "Dependency Hierarchy". In the filter type the name of the jar file we found in the previous step (in my case it was xml-apis).
This will pull up the dependencies creating the problem. A screen shot of the Dependencies Hierarchy filtered for "xml-apis". From this we can see the offending dependencies in our pom.xml file are xercesImpl and xlsx-streamer.
Solving the problem
We can now add exclusions to these dependencies that will resolve the problem as shown below.
<dependency>
<groupId>com.monitorjbl</groupId>
<artifactId>xlsx-streamer</artifactId>
<version>2.1.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.12.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
And this fixes the current problem.

For anyone who suffer with this problem when refering to the org.w3c or javax.xml imports, be careful with this one module dependency: xml-apis it conflicts with java default xml classes.
One big project who references it is called DynamicJasper

Here's the image of my app
It seems to me the real problem here is that the JDK (in my case, JDK-19) has org.w3c.dom embedded in it, so everything else that was doing the correct thing by referencing libraries from external-lib, rather than embedding is now broken. I removed xml-apis and xerces, but it still complains about org.w3c.dom. the only place it is referenced in my project is the JDK.
Removing jar files, (xml-apis.jar and xerces_2_5_0.jar) Does not fix the issue. I cannot remove batik, project depends upon it.
I have a standard Java build, no maven. There is no decompiling/removing a valid reference that can be done with 3rd party software like batik.
Any suggestions on how to remove the embedded org.w3c.dom from JDK-19 so I can build?

I had this problem with the Stanford Core NLP package. As mentioned above adding an exclusion in the pom.xml solved the problem:
<dependency>
<groupId>edu.stanford.nlp</groupId>
<artifactId>stanford-corenlp</artifactId>
<version>4.5.2</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>

First of all, make sure your pom is actually correct by running
mvn install
if that works, and eclipse still complains look at build path and find the library it is holding onto that is not in your pom.
Sometimes I just
rm .classpath
rm -rf .settings
rm -rf project
mvn eclipse:clean eclipse:eclipse

SAXNotRecognizedException when adding project to weblogic through eclipse

We have a maven project which successfully builds when we do it from CLI.
Unfortunately when we try to add the project on weblogic through eclipse the following exception is thrown:
18-05-23 10:27:35 ERROR digester.Digester - Digester.getParser:
org.xml.sax.SAXNotRecognizedException:
http://apache.org/xml/features/validation/dynamic at
oracle.xml.jaxp.JXSAXParserFactory.setFeature(JXSAXParserFactory.java:128)
at
org.apache.commons.digester.parser.XercesParser.configureXerces(XercesParser.java:185)
at
org.apache.commons.digester.parser.XercesParser.newSAXParser(XercesParser.java:138)
at
org.apache.commons.digester.ParserFeatureSetterFactory.newSAXParser(ParserFeatureSetterFactory.java:71)
We have the following as a dependency:
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.9.1</version>
</dependency>
Any suggestion on how to overcome this problem?

If it successfully builds from Maven, but does not work in Eclipse, it must be a difference in the JDK being used or the classpath.
My guess is that you have more than one XML library on your classpath and, due to the ordering of the classpath, a different one is taking precedence in each case.
To list the classpath in Maven:
mvn dependency:build-classpath -Dmdep.outputFile=cp.txt
Manually compare the ordering with the Eclipse one (in the .classpath file), paying particular attention to any JARs that may contain XML libraries. If any JARs are missing or in a different order, adjust them to match the Maven classpath.

Maven dependencies for IBM Websphere packages

I'm trying to convert a "classic" JAVA EE project, using IBM websphere 8.0.0.5, into a maven multi module project and facing issues with the IBM dependecies.
We use IBM classes from the following packages:
com.ibm.websphere.asynchbeans
com.ibm.websphere.scheduler
com.ibm.websphere.ce.cm
com.ibm.ws.asynchbeans
com.ibm.ws.util.ThreadPool
To get my local project to be compiled I downloaded the was.installer-8.0.0.pm from IBM and installed it to my maven using
mvn install -f "was.installer-8.0.0.pom" -D serverInstallationFolder="C:\Program Files (x86)\IBM\WebSphere\AppServer"
This step was successfull according to command line output.
I then added the following dependencies to my project as described from IBM:
In parent:
<dependency>
<groupId>com.ibm.tools.target</groupId>
<artifactId>was</artifactId>
<version>8.0.0</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
In module:
<dependency>
<groupId>com.ibm.tools.target</groupId>
<artifactId>was</artifactId>
</dependency>
But I still can't compile my project as the IBM packages are not found.
Can anyone help me to find and correct a mistake I made?
Edit
After following BevynQ tip from the comments I copied the "was_public.jar" to "was_public-8.0.0.jar" (described at IBM here) and added it to my repository:
mvn install:install-file -Dfile="C:\Program Files (x86)\IBM\WebSphere\AppServer\dev\was_public-8.0.0.jar" -DpomFile="C:\Program Files (x86)\IBM\WebSphere\AppServer\dev\was_public-8.0.0.pom"
I then changed the dependencies to:
<dependency>
<groupId>com.ibm.websphere.appserver</groupId>
<artifactId>was_public</artifactId>
<version>8.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.ibm.websphere.appserver</groupId>
<artifactId>was</artifactId>
</dependency>
This helped to get the compiling errors for the imports to com.ibm.websphere done.
What I now have still open is the packages com.ibm.ws.* package. Anyone have an idea?
Edit 2
I added the following dependency and then I was rid of the com.ibm.ws.* import errors.
<dependency>
<groupId>com.ibm.websphere.ws</groupId>
<artifactId>com.ibm.ws.runtime</artifactId>
<version>1.0.0</version>
</dependency>
But it still does not compile as now indirectly references can not be found (in my case commonj.work.WorkManager). It seems I need to add further .jars for every single thing. Isn't there an easier way to provide all websphere jars at once as descirbe in the above linked tutorial with the com.ibm.toolsdependency (which do not work)?

In general, com.ibm.websphere are public API for use by applications (this is true of the packages you listed above) which is consistent with these being in was_public.jar
However, com.ibm.ws package is generally product internals. May I ask what interface methods you are using from the com.ibm.ws.asynchbeans package? Maybe there is a public API alternative.
Regarding commonj.work, the only place I can find this in the WebSphere Application Server product image is WAS/plugins/com.ibm.ws.prereq.commonj-twm.jar so it looks like you will need to use that to compile against.

Here's the solution so I solved my dependency problems:
I configured the company repository manager (nexus) as a mirror. In this nexus all ibm packages are present. As you can think that solved the main problem.
I then added the following dependencies according to common maven style:
Dependencies in pom.xml (version numbers extracted to properties):
<dependency>
<groupId>com.ibm.websphere.ws</groupId>
<artifactId>com.ibm.ws.runtime</artifactId>
<version>${ibm.ws.runtime.version}</version>
</dependency>
<dependency>
<groupId>com.ibm.ws.prereq</groupId>
<artifactId>commonj-twm</artifactId>
<version>${ibm.ws.prereq.commonj-twm.version}</version>
</dependency>
Sorry I can't provide a "nice" solution that's useable by all people but the answer from njr and the comment from BevynQ helped at lot to get clearer with the problem and helped to solve the problem in a "more manual" way by copying the needed jars by hand.

I was facing this issue as I tried to build a project using Maven version 3.3.9, running on Java version 1.8.0_101, as depicted in the screenshot:
This is how I resolved it: Step 1. Download the commonj.jar from here.
Step 2. Determine which JDK your Maven is using by typing mvn -version in the command prompt.
Step 3. Go to that directory and place the commonj.jar file there in the jre/lib/ext directory, as shown below. Now your project should build in maven without any issues.

Missing tools.jar in local repository breaks m2eclipse

The problem I'm experiencing is that eclipse can't resolve any of the dependencies of my project. This causes problems because even though the dependencies seem to work alright when coding (I get autocompletion) I still get a huge list of errors referring to missing artifacts.
When filtering these, I found the following:
The container 'Maven Dependencies' references non existing library '/home/[...]/.m2/repository/com/sun/tools/1.5.0/tools-1.5.0.jar'
It seems that this dependency was introduced by struts2, who have a profile set up as follows in their pom:
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
That systemPath resolves and so I don't see a reason why this would be causing trouble. In any case, is there a way to tell eclipse that this m2eclipse dependency is a system dependency that is not found in the local repository?

I was facing the same problem and needed to do the following things
Added -vm path/to/jdk/bin in eclipse.ini file
Clean the existing workspace and reload the project.
It worked for me seamlessly.
Its worth to add that, in my eclipse.ini file I had to add the -vm ... lines at the top of the file. like
-vm
C:\Program Files\Java\jdk1.6.0_27\bin
... ... ...
Make sure that, -vm option is placed before -vmargs as everything after -vmargs is passed directely to vm and selecting a particular is depend on -vm option.

I had this issue, but I have fixed by using the steps below:
Case1:
Eclipse by default pointing to JRE but eclipse maven plugin required JDK so point to JDK
Window -> Preperences -> Java -> Installed JREs
change it to JDK
Follow the steps to change to JDK from JRE
In the Eclipse IDE go to: Window… Preferences… Installed JREs
Select defaulted JRE and click on Edit.
Click on Add External Jar
I found tools.jar in “C:\Program Files\Java\jdk1.6.0_22\lib” and added.
Now I can build my project without any issue. Is this the correct way to solve this issue?

I had the same problem - Eclipse couldn't find a tools.jar. As I found out the reason is that Eclipse used a JRE and not a JDK. You have to add a -vm parameter to eclipse.ini that is pointed to your JDK bin directory:
...
-vm
path_to_jdk\bin
...
This should fix the problem.

excludes tools jar from the struts dependency.
<exclusions>
<exclusion>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
</exclusion>
</exclusions>

Download http://repository.ops4j.org/maven2/tools/tools/1.5.0/
and put the jar in the C:\Documents and Settings\Administrador\.m2\repository\com\sun\tools\1.5.0. Good luck.

You need to verify that Eclipse is using JDK installs.
In Eclipse IDE go to
Window / Preferences / Java / Installed JREs
point to a JDK installation.
For example: C:\Program Files (x86)\Java\jdk1.6.0_37

I read this and tried various things. What worked for me was this: I changed the windows --> preferences --> java --> installed JREs to point to the JDK instead. That solved this problem.

As strange as this may sound, I solved this issue by just re-synchronizing with the SVN repository.
The thing is, I took the entire workspace from another PC, so when I imported the maven project using the m2e plugin, maybe some dependencies didn't synchronize correctly.
I'm posting this just in case someone is desperate with this error and trying all possibilities.

In each project you import into Eclipse, Eclipse makes some files on filesystem - .project, .classpath, a folder .settings,. It seems that Eclipse doesn't update these correctly.
Delete these and import them again.
Clearly, this workaround won't work if this is your 1st import and you already have obtained some issues. Than have a look here Maven2: Missing artifact but jars are in place

I also had a similar issue and fixed it the following way. Go to lib directory of JDK installed path in command prompt. Execute the below command to install to install tools.jar.
$mvn install:install-file -DgroupId=sun.jdk -DartifactId=tools \
-Dpackaging=jar -Dversion=1.6 -Dfile=tools.jar

<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.6.0</version>
<scope>system</scope>
<systemPath>${env.JAVA_HOME}/lib/tools.jar</systemPath>
</dependency>
Just add this. It will work.

This dependency should work as expected. If in doubt, try the command line version of Maven because the Eclipse plugin is very brittle when it comes to dependency resolution.
Unlike other parts of Eclipse, it is unable to create even a partial classpath for the build if something is wrong with the POM, so the error could be something else.
If all else fails, try to install the file into your local repository, so you can see the next error.

I eventually found what was causing it. Seemingly it's a bug in m2eclipse when you are using maven1 repositories. I still had the java.net maven1 repository in my pom; after disabling it everything works again. A very annoying problem to track down because in the end it had nothing to do with finding the tools jar.

For Mac users
[1] To find out where your VM is type this
/usr/libexec/java_home
[2] vi ./Eclipse.app/Contents/MacOS/eclipse.ini
[3]
-vm
/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/
-vmargs
........
........
[4] In Eclipse , Update Maven
[5] Sing All is Well :-)

I had the same issue several times and I could fix it following two steps:
I added "-vm C:\\bin" to eclipse.ini or to the link from which I run eclipse.
After having this problem many times, I began to suspect that there may be some m2eclipse cache that is reloaded after some time (one day or so), so I tried a weird solution: temporarily changing the computer time to the following day and restarting Eclipse or closing/cleaning the project and.... IT WORKED!!!
I could repeat the process several times successfully.
A more elegant solution (I haven't had the chance to try it yet), might be to clear m2eclipse caches mentioned at https://stackoverflow.com/a/16444984.
Hope this will help anyone.

This issue due to wrong java configuration. every IDE required full JDK pack. becuase tools.jar available inside JDK lib not jre lib
go to control panel change environment path variable to C:\Program Files\Java\jdk1.8.0_31\jre\bin.
change JAVA_HOME to C:\Program Files\Java\jdk1.8.0_31.
open IDE(eclipse or STS) change JRE system library to C:\Program Files\Java\jdk1.8.0_31
then restart IDE. it will work

A hacky solution that worked for me:
If m2e is complaining that the following jar is not found in the Maven cache (you can find the bad path in the error log for the pom file, or in the "Java Build Path > Maven Dependencies" list):
${HOME}/.m2/repository/jdk/tools/jdk.tools/1.6/jdk.tools-1.6.pom
then try the following command (fill in JAVA_VERSION_HERE for an installed JDK, e.g. jdk1.8.0_191-amd64, then use the two path sections after .m2/repository/ above to determine the correct groupId, and replace 1.6 with whatever version m2e is complaining about -- it may or may not matter if the JDK you have installed matches the version m2e is complaining about):
mvn install:install-file -Dfile=/usr/java/JAVA_VERSION_HERE/lib/tools.jar \
-DgroupId=jdk.tools -DartifactId=jdk.tools -Dpackaging=jar -Dversion=1.6
This command copies tools.jar from your JDK and puts it into the Maven cache, also creating a pom.xml file for it so that it can be used by Maven.