mvnw，到底是什么鬼？
來自公眾號：小姐姐味道
作者簡介：小姐姐味道?，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。
使用start.spring.io生成項目，會發(fā)現(xiàn)里面有mvnw和mvnw.cmd兩個文件。兩個文件加起來有20多kb。
我代碼還沒超過20行呢，就整上這樣兩個文件，做什么用呢？到底是什么鬼？
官方說，它是maven的一個wrapper，在找不到maven的時候，它會自動下載一個；或者，碰到你的項目maven和你環(huán)境里的mavne不兼容，它也會自動下載一個。
這不是在搞笑么？不知道我現(xiàn)在身處局域網(wǎng)深處么？
我們嘗試執(zhí)行一下傳統(tǒng)的mvn命令，可以看到它使用mvnw去替換了自己。
~/codes/ $ mvn -Dmaven.test.skip=true -Pdev package
executing mvnw instead of mvn
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:225)
at java.util.zip.ZipFile.(ZipFile.java:155)
at java.util.zip.ZipFile.(ZipFile.java:169)
at org.apache.maven.wrapper.Installer.unzip(Installer.java:169)
at org.apache.maven.wrapper.Installer.createDist(Installer.java:86)
at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)
但是但是，等了良久，日志也沒有向下滾動。等了十幾分鐘，好不容易有輸出了，結(jié)果報錯。然后接下來每次運行都報錯。
聒噪的很，是時候要讓它露出真面目了。
使用ps命令，找到了它的啟動參數(shù)。這才發(fā)現(xiàn)，除了mvnw文件，它還偷偷的在項目中放了.mvn目錄，好家伙，足足有64kb。
# ps -ef| grep mvn
java -classpath ~/codes/.mvn/wrapper/maven-wrapper.jar -Dmaven.home=~/codes -Dmaven.multiModuleProjectDirectory=~/codes org.apache.maven.wrapper.MavenWrapperMain -Dmaven.test.skip=true -Pdev package
這可真是多此一舉，不如不舉。你要是貼心，直接塞個apache maven在里面啊。
深處國內(nèi)，對付這玩意最好的方式，那就是：
刪掉它！
刪掉它！
刪掉它！
即使它的初衷如何好，目標是如何宏大，還是要毫不留情的干掉它。
曾經(jīng)有個小弟，使用mvnw下載了一下午的jar包，最后茫然的向我吐槽：公司的maven私服太慢了。
不能背這個鍋。
一個好的項目，不會依賴特定的打包工具。這算是maven項目偷懶出的插件，因為一個基礎(chǔ)工具，有一個點必須要做到，那就是向后兼容。
搞出這么個工具，連個CDN都舍不得弄，這不是方便開發(fā)人員，而是給開發(fā)人員添亂。
更要命的是，企業(yè)內(nèi)部都是自己搭建maven私服的，有自己的配置文件和賬號。使用這個玩意，還得需要知道m(xù)aven下載在哪了，找到以后替換它的配置文件。典型的管生不管養(yǎng)啊。
當(dāng)然了，gradle也是一個德行。
所以，xjjdog的處理方式是，看到mvnw和.mvn這些文件，第一時間就毫不留情的干掉它。
雖然我很殘忍，辜負了作者的一片好心。但深處這樣的網(wǎng)絡(luò)環(huán)境之中，我也是無奈之舉啊。
推薦閱讀 海量交易訂單查詢沒做“重試”，一哥們“喜提”P3故障！ 聰明的項目經(jīng)理，都會利用周報讓老板重視你！ MySQL百萬數(shù)據(jù)，你如何用分頁來查詢數(shù)據(jù) 你的Redis為什么變慢了？