If you want to try out lint, or run it one time with minimal hassle and no config changes, follow these simple steps:
[...]
<build>
<plugins>
<plugin>
<groupId>com.lewisd</groupId>
<artifactId>lint-maven-plugin</artifactId>
<version>0.0.8</version>
<executions>
<execution>
<id>pom-lint</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
3. Build your project as usual (usually "mvn install"). The build will fail if lint finds a problem.
<plugin>
<groupId>com.lewisd</groupId>
<artifactId>lint-maven-plugin</artifactId>
<version>0.0.8</version>
<configuration>
<failOnViolation>false</failOnViolation>
<onlyRunRules>
<rule>ExecutionId</rule>
</onlyRunRules>
<xmlOutputFile>${project.build.directory}/maven-lint-result.xml</xmlOutputFile>
</configuration>
<executions>
<execution>
<id>pom-lint</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
mvn com.lewisd:lint-maven-plugin:list
The convention is to specify properties used to hold versions as some.library.version, or some-library.version, but never some-library-version or some.library-version.
The ${version} property is deprecated. Use ${project.version} instead.
Maven convention is that the groupId, artifactId, and version elements be listed in that order. Other elements with short, simple content, such as type, scope, classifier, etc, should be before elements with longer content, such as configuration, executions, and exclusions, otherwise they can be easily missed, leading to confusion.
Dependency versions should be set in one place, and not overridden without
the version. If, for example,
Plugin versions should be set in one place, and not overridden without changing
version. If, for example,
Profiles who's ids match the pattern with-.* must only add modules to the reactor.
Multiple dependencies, in
Executions should always specify an id, so they can be overridden in child and uniquely identified in build logs.
The users/developers need to know where to get active bugs and to report new to.
For better understanding the project a link to the used integration system users to trust.
For better understanding the project the inception year of your project is required.
The users/developers need to know where to get active bugs and to report new to.
Each project should be licensed under a specific license so the terms of usage clear.
For better understanding the project a link to your project is required.