[Maven Essentials] coordinates and dependencies

Coordinate element: the actual project to which the current maven project belongs. Maven projects and actual projects are not necessarily one-to-one. ArtifactId defines a maven Project (module) in the actual project. We recommend that you use the actual project name as the prefix of artifactId. Version defines the current version of the maven project. Packaging defines the packaging method for maven projects. The default value is jar. Classifier is used to help define ancillary builds of build outputs. For example, the source code jar package and the document jar package. This element cannot be directly defined and needs to be generated through an additional plug-in. The file name of the component corresponds to the coordinate. Generally, the rule is artifactId-version [-classifier]. packaging, where classifier is optional. Example: [html] <groupId> com. example. project </groupId> <artifactId> backend </artifactId> <packaging> jar </packaging> we recommend that you change artifactId from backend to project-backend, this is because if there is still a project named xxx, and if there is also a backend module (sub-project), the last two modules will generate an output called a backend-version.jar, this is not conducive to location and resolution. Dependency configuration: for example, in the project pom. in the xml file: [html] <dependencies> <dependency> <groupId> com. example. project </groupId> <artifactId> project-cms </artifactId> <version >$ {project. version }</version> <exclusions> <exclusion> <groupId> cglib </groupId> <artifactId> cglib </artifactId> </exclusion> <groupId> jboss </groupId> <artifactId> javassist </artifactId> </exclusion> </exclusions> </dependency> ...... </Dependencies> the dependencies tag defines several dependency elements. Each dependency element contains the following elements: groupId, artifactId, and version, which are the basic coordinates of dependencies, this is the three most important elements, because only the three coordinates can be used to find the required dependencies. Type depends on the type, which corresponds to the packaging defined in the project coordinate. In most cases, it does not need to be declared. Its default value is jar. Scope. The default value is compile, and test, provided, runtime, and system are also available. Optional indicates whether dependency is optional. Exclusions is used to exclude the passed dependency. Dependency scope: the default dependency scope of compile and the dependency scope of compile are effective for compiling, testing, and running classpath. Test dependency scope. This dependency is only valid for testing classpath and cannot be used when compiling the main code or running the project. Typical examples include JUnit. Provided to provide the dependency scope. It is valid for compiling and testing classpath, but not for running. Typical examples are required for compiling and testing projects such as servlet-api. However, when running a project, you do not need to introduce it again because the container has already provided it. Runtime dependency scope. It is valid for testing and running classpath, but not for compiling the main code. A typical example is the JDBC driver. System dependency scope. The dependency of classpaths is the same as that of provided. However, the dependency within the system range must explicitly specify the path of the dependent file through the systemPath element. This type of dependency is not parsed through the maven repository and is often bound to the local system, which may cause the build to be unportable and should be used with caution. Import dependency scope. See the post-order document. For example, compileYESYESYES is the default dependency scope testNOYESNOJUnitprovidedYESYESNOservlet-apiruntimenoyesjdbc driver to implement local systemYESYESNO, and class library dependencies outside maven repository pass: for example, in the project-backend project, the following dependency is introduced to use reflection functions: [html] <dependency> <groupId> org. reflections </groupId> <artifactId> reflections ctions </artifactId> <version> 0.9.8 </version> </dependency> The component also has other dependencies, you can access the pom file of this component to view: [html] <depend Ency> <groupId> com. google. guava </groupId> <artifactId> guava </artifactId> <! -- <Version> 12.0 </version> --> <! -- Jdk1.6 + --> <version> 11.0.2 </version> <! -- Case: when only jdk1.5 isacceptable --> </dependency> you can see that this component is dependent on Google's guava project. Therefore, in the final Actual dependency component, the guava component will be added to the maven dependency in the form of passing dependencies.