Maven的工程构建确实给程序员带来了不要的福音,想想曾经的我们jar包都是一个个的下载,再碰到版本兼容的问题,折腾许久,痛不欲生...
Maven采用一种被称之为project object model(POM)的概念来管理项目,可以在非常短的时间里完成配置,大大简化工程的创建、报表、检查、构建和自动化测试的设置的工作。然而遗憾的是好多的工程创建者(那些所谓的架构师们)项目仅仅使用Maven来管理包的依赖,简化jar包的下载...做为maven使用者请从以下方面来考虑修改你的POM,别让你的工程输在起跑线上(这不是广告)
标准的工程结构
曾几何时流行一种基于约定的做法,Maven大约也受此影响(我杜撰的,就不要考证了)对每一个文件夹都建议了它的作用和名称
Maven Standard Directory Layout
真真切切的问题是违反这个结构的所增加的成本,曾有多少次你在调试时都无法认识别出资源文件。连神级的IDEA也识别不出.违反的成本就是神也帮不了你.当然了不是一定不可违反只是我不告诉你!
[1] 工程建立的起势
起势有多重要,李小龙和李连杰的起势就不一样 :-)
帅帅的起势Maven也有
mvn archetype:generate
一阵风雨过后等待你出招,请选择maven-archetype-quickstart,一般情况应该是默认选好的。接下来会让你输入一些项目的信息:
Define value for property 'groupId': icloudyin.com
Define value for property 'artifactId': mvn-starter
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package' icloudyin.com:
最后你将见到一个大大的BUILD SUCCESS,像这样
[INFO] BUILD SUCCESS
一个最最基本的maven工程已经建立。你可以再试上几个mvn命令。完整的maven 工程的构建阶段请参考introduction-to-the-lifecycle
工程的建立请从archetype开始,那么多的archetype总有一款使合你!
[2] 让你的代码接受style的考验
在代码之丑中我们已经讲过了没有style的代码是何其的悲剧...
打开pom.xml文件加入以下内容
org.apache.maven.plugins
maven-checkstyle-plugin
2.17
verify-style
validate
google_checks.xml
UTF-8
true
true
false
check
现在执行mvn validate
mvn validate
你将看到一此warning信息。我们做了什么?在validate周期内加入了代码格式检查插件,并且使用google的风格,从而保证后来的开发者的加入,不会引起代码五官上的变化。如果感觉google的风格过严,请修改自己的价值观。(不会告诉你怎么自定义的)。
maven-checkstyle-plugin目前内置两个代码风格 sun_checks.xml 和 google_checks.xml. 更多信息请参考maven-checkstyle-plugin。
[3] 为代码加上保护伞
有程序员的地方,就会有BUG,我不在调BUG,就在写BUG的路上...google的大神们已经总结了大家共同会犯的错误,那就是error-prone。一句话就是让“catches common programming mistakes at compile-time”。
同样的打开pom.xml,在plugins标签中加入!
org.apache.maven.plugins
maven-compiler-plugin
3.3
javac-with-errorprone
true
7
org.codehaus.plexus
plexus-compiler-javac-errorprone
2.8
com.google.errorprone
error_prone_core
2.0.19
为了确保error-prone可以工作,我们需要在建立的工程加入错误的代码。
新建一个文件ShortSet:来自于error-prone示例
public class ShortSet {
public static void main (String[] args) {
Set s = new HashSet<>();
for (short i = 0; i < 100; i++) {
s.add(i);
s.remove(i - 1);
}
System.out.println(s.size());
}
}
执行mvn compile
$ mvn compile
.../icloudyin/com/ShortSet.java:16: error: [CollectionIncompatibleType] Argument 'i - 1' should not be passed to this method; its type int is not compatible with its collection's type argument Short
s.remove(i - 1);
^
(see http://errorprone.info/bugpattern/CollectionIncompatibleType)
1 error
[INFO] --------------------------
[INFO] BUILD FAILURE
[INFO] --------------------------
是的在编译阶段,就已经BUILD FAILURE。在这个世界里面没有什么东西是可靠的!记着把错误放在编译阶段...
[4] 带给自己带上紧箍咒
总有一些人在写完代码忘记了一件事,整理代码,如无效的包导入,或未使用的变量定义,作为在一个工程师,这个是要注意的!如果来约束他们?加插件...
同样的再一次打开POM,增加
org.apache.maven.plugins
maven-pmd-plugin
3.7
pmd-plugin
compile
true
check
来测试一下,打开ShortSet.java 注释掉:
// for (short i = 0; i < 100; i++) {
// s.add(i);
// s.remove(i - 1);
// }
// System.out.println(s.size());
执行mvn compile
$ mvn compile
[INFO] --- maven-pmd-plugin:3.7:check (pmd-plugin) @ mvn-starter ---
[INFO] PMD Failure: icloudyin/com/ShortSet.java:3 Rule:UnusedImports Priority:4 Avoid unused imports such as 'java.util.HashSet'.
[INFO] PMD Failure: icloudyin/com/ShortSet.java:4 Rule:UnusedImports Priority:4 Avoid unused imports such as 'java.util.Set'.
[INFO] ----------------------------------
[INFO] BUILD FAILURE
[INFO] -----------------------------------
同样的编译出错了,有说人这个太严了不方便测试,难道代码不是应该写完之后再测试的么。放纵即意味着犯错,如果有问题请参考第一篇:从尊敬一事无成的自己开始
现在开始真正的去写程序吧,有风格,常规错误,还有pmd为我们保驾护航,从此开心无极限...然而有一天开发经理说,你们单元测试做的怎么样啊,现在有多少个UT?执行怎么样啊?LLT达标了没有?他们的要求总是那么的不礼貌~怎么办?怼回去啊,但前提是你得有准备...
[5] 生成报告完美谢幕
Maven已经为我们准备了怼回去的资本...只需要生成site report.
打开POM文件,加入
org.apache.maven.plugins
maven-project-info-reports-plugin
2.7
false
org.apache.maven.plugins
maven-surefire-report-plugin
2.19.1
org.codehaus.mojo
cobertura-maven-plugin
2.6
html
xml
然后执行:
mvn site
一切都已就绪, 打开target/site/index.html
拿上这些数据把开发经理给怼回去...
另请:关注公众号实时获取枪炮,icloudYin长期提供火力支援