In actual development, the project manager always tells the developer: what kind of conventions to follow when developing, how to name the specification ....
The agreement is superior to the configuration, it is very important! A more regulated company (or project team) will write the specification to the document and let the developer follow it.
The question is, how can we know if everyone has gone according to the standard? Someone will say, find a tool to check it on, there are many open source tools. Yes, that's right. But for the project used in the program, tools, development environment, people who have work experience should know, many times, novice strange problems, part of the reason is because the environment is not right, or the software version does not match;
MAVEN provides a Maven-enforcer-plugin plug-in for verifying compliance (or verifying the development environment). For example, the JDK version, the MAVEN version, the development environment (linux,windows, etc.), depending on the jar package version, and so on; Website address:
http://maven.apache.org/enforcer/maven-enforcer-plugin/
The use of this plug-in is described below:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactid>maven-enforcer-plugi
n</artifactid> <version>1.3.1</version> <executions> <execution>
<id>enforce</id> <phase>validate</phase> <goals> <goal>display-info</goal> <goal>enforce</goal> </go als> </execution> </executions> <configuration> <!--rule checking fails to build failure; D Efault:false. --> <!--<failFast>true</failFast>--> <rules> <requiremavenvers ion> <version>3.0.4</version> </requireMavenVersion> &L
T;requirejavaversion> <version>1.6.0</version> </requireJavaVersion> <bannedDependencies> <!--whether to check for transitive dependencies (indirect dependencies)--> <searchtransitive>true </searchTransitive> <excludes> <exclude>junit:junit</exclude&
Gt </excludes> <message>must Use testng</message> </BANNEDDEPENDENCIES&G
T </rules> </configuration> </plugin>
The plug-in is verified based on <rules>, and the above three rules are configured:
Requiremavenversion indicates that the version of MAVEN is greater than or equal to 3.0.4;
Requirejavaversion indicates that the JDK version is greater than or equal to 1.6.0;
Banneddependencies represents a prohibited dependency, with the following configuration available:
Searchtransitive: whether search indirect dependence;
Excludes: Prevent dependency list, its representation format is groupid[:artifactid][:version][:type][:scope] [: classifier] in parentheses is optional, you can use wildcard characters to replace the whole or part; The following demo is valid:
<excludes>
<!--groupid[:artifactid][:version][:type][:scope][:classifier]-->
<exclude>org.log</exclude>
<exclude>org.log:log4j</exclude>
<exclude>org.log:log4j:1.0</exclude>
<exclude>org.log:*:1.2</exclude><!--excluding 1.2 and above, equivalent to [1.2,)-->
<exclude>org.log:*:[1.2]</exclude><!--explicitly excludes version 1.2-->
<exclude>org.log:*:*:jar:test</exclude>
<exclude>*:*:*:jar:compile:tests</exclude>
<exclude>org.apache.*:maven-*:* </exclude>
</excludes>
Includes: List of dependencies excluded from prohibited dependencies (this property can be used to exclude when excludes uses wildcard characters);
Message: Checksum failure, print the prompt information;
If you want to configure a more complex version range, refer to: http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
In addition to the above configuration, the plugin has many other rules built into it, with a complete list of built-in rules in: http://maven.apache.org/enforcer/enforcer-rules/index.html
MAVEN defaults to provide a variety of checksum rules to meet our various requirements, while providing MAVEN-ENFORCER-RULE-API allows us to customize the rules, see also: http://maven.apache.org/enforcer/ Enforcer-api/writing-a-custom-rule.html
Add the following (important):
Maven has so far provided no Java-like @deprecated annotations for declaring dependency obsolescence. Because of the incorrect, obsolete, obsolete dependencies that are introduced in Pom.xml, the unwanted jars (especially the conflicting jars) can easily be introduced because of the dependency-passing nature of maven.
Based on this situation, the use of Maven-enforcer-plugin Plug-ins can achieve the above purposes.