First, today to build a maven project, after the introduction of the pom.xml file dependency is not found in the project structure Maven Dependencies file (below), but it can find Maven Dependencies file (as shown below) in java Build Path in:
However, pom.xml file, add the dependent jar package will not be automatically downloaded to the project, update Project is the same, so is the Internet to find a lot of ways, have found no use after the attempt, eventually, see your pom.xml file found to be in front of dependent wrote <dependencyManagement> label (figure below), check the information found after the effect of this tag only declared dependent and does not achieve the introduction of dependent, therefore, does not introduce jar package, maven project will not display Maven Dependencies file. After removing the label, problem solving, maven Dependencies file appears in the maven project.
Second, other online methods to resolve Maven Dependencies missing files:
the first type: Maven support is not open: This is generally Eclipse comes with Maven, Maven or own equipment and did not open the service.
Solution: Right Maven Project -> Maven -> Enable Dependency Management
(There may be some version of maven no Enable Dependency Management this option)
The first two kinds: classpath file problem or question .project file:
Solution:
(1) add the following code .classpath file:
<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
<attributes>
<attribute name="maven.pomderived" value="true"/>
<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>
</attributes>
</classpathentry>
（2）在.project文件的<natures>中添加下面这行语句：
<nature>org.eclipse.m2e.core.maven2Nature</nature>
<natures>
<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.m2e.core.maven2Nature</nature>
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
</natures>
第3种：项目-->properties-->Deployment Assembly-->Add-->java build path Entries-->Maven Dependencies--Finish
Fourth: non maven Project Project (less frequently)
Solution: Right Project -> configure -> Convert to Maven Project
Three differences, dependencyManagement and dependencies of:
the part transferred from blog: https: //blog.csdn.net/liutengteng130/article/details/46991829
Front of the main problems is because there is no clear distinction dependencyManagement and dependencies, so this section summarizes the main difference between these two pom.xml file tags:
1, DepencyManagement application scenarios:
When a lot of time our project module, we use the Maven project management is very convenient, to help us build management, documents, reports, dependence, scms, publishing, distribution method. You can easily compile the code, dependency management, management of binary libraries and so on.
Because many of our modules, so we have a layer of abstraction, taking a itoo-base-parent to manage the public's reliance subprojects. For proper operation of the project, we must make use of all of the sub unified version of dependency, dependency and the need to ensure consistent application of the various versions of the project, to ensure the release of the test and the result is the same.
In our project top level POM file, we will see dependencyManagement elements. Through its elements to manage jar package version, let subproject cited a reliance version number listed without display. Maven will walk up the parent-child hierarchy until it finds a project has dependencyManagement elements, then it will use the version number specified in this dependencyManagement element.
To look at the application of our project: pom inheritance diagram:
itoo-base-parent(pom.xml)
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<version>${org.eclipse.persistence.jpa.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>${javaee-api.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
itoo-base(pom.xml)
<!--继承父类-->
<parent>
<artifactId>itoo-base-parent</artifactId>
<groupId>com.tgb</groupId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../itoo-base-parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>itoo-base</artifactId>
<packaging>ejb</packaging>
<!--依赖关系-->
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</dependency>
<dependency>
<groupId> org.eclipse.persistence </ groupId>
<artifactId> org.eclipse.persistence.jpa </ artifactId>
<scope> Provided </ scope>
</ dependency>
</ the Dependencies>
</ Project>
benefits of doing so : unified management project version numbers, dependencies and ensure consistent application of the various versions of the project, to ensure the release of the test and the results are the same, therefore, the definition of a common dependence on the top floor of the pom. And will avoid all declared in each subproject use of a version number, so when you want to upgrade or switch to another version, only need to update the parent container, a sub-project does not require any modification; if a subproject when need another version, just declare a version number at the dependencies in. Subclass will use the version number of the subclass declaration, not inherited from the parent class version number.
2、Dependencies：
Relative to dependencyManagement, all statements will depend on dependencies in the automatic introduction, and default is inherited by all sub-projects.
3, the difference between:
(1) dependencies: automatic introduction declare all depend on where the dependencies, and default is inherited by all sub-projects. If you do not write the project dependencies, it will inherit (all inherited property) declare dependencies in the parent project dependencies in the project from the parent.
(2) dependencyManagement: This tag only declared dependent and does not achieve the introduction of the statement and therefore subprojects to be displayed dependent on the need. If you do not declare a dependency subproject, is not inherited from the parent project down; only write the dependencies in subprojects, and does not specify a specific version, will be inherited from the parent project, and version and scope They are read from a parent pom; Also, if the version number is specified in sub-project, it will use the specified jar in subprojects version.
(3) dependencyManagement dependencies do not affect the project dependencies; dependencies element independent of the influence of the dependency item. Only when the outer layer of the element dependencies did not specify the version information, dependencies element dependencyManagement in to work. A project is dependent on, one is dependent on management control for multi-module maven project situation.