我不會參加整個Maven辯論，但是可以說我是所有最佳實踐的有力支持者，對我而言，Maven是最佳實踐的體現(xiàn)。 我的意思是說，Maven是圍繞特定的最佳實踐構(gòu)建方法構(gòu)建的。 注意，我說了一種特定的最佳實踐構(gòu)建方法。 在現(xiàn)實世界中，有不止一種構(gòu)建方法可以勝任最佳實踐，但是Maven假設(shè)其中只有一種。 這并不意味著其他人都不好，而只是意味著如果您使用Maven，則需要接受其假定的約定 。 。 。 或受苦。 對于任何“約定優(yōu)于配置”（CoC）工具來說都是如此，并且Maven是相當糟糕的CoC。

像所有設(shè)計模式一樣，Maven是構(gòu)建軟件過程的可重用解決方案。

我認為偶爾討論的Maven作為構(gòu)建設(shè)計模式的概念是一個強有力的隱喻。 它很有用，因為它強調(diào)Maven與所有設(shè)計模式一樣，是構(gòu)建軟件過程的可重用解決方案。 這是一個最佳實踐解決方案，經(jīng)過多年的大量使用，這些社區(qū)已經(jīng)由聰明人改進。 利用設(shè)計模式構(gòu)建軟件的最明顯好處與編寫軟件的好處相同。 即：

• 您無需手動編寫即可獲得大量功能
• 了解適用于一個項目的模式的工程師可以立即了解適用于另一項目的模式。

名義上，第一個是生產(chǎn)力，第二個是簡單。 顯然，每個人都希望提高生產(chǎn)力，即用更少的代碼行完成更多工作。 但是，我實際上認為第二點-簡單-更為重要。 我認為，整個工程領(lǐng)域可以歸結(jié)為“管理復(fù)雜性”的概念。 就復(fù)雜性而言，我直接指的是當您被成堆的意大利面條代碼轟炸時感到的頭痛。 設(shè)計模式通過以較高級別的注釋密封大量的復(fù)雜性，有助于消除這種智力上的矛盾。 萬一您忘記了，這就是我們騰出更多精力處理不可避免地駐留在下一個級別上的更大更酷的任務(wù)的原因。

正是這種觀點使我將學習新項目的臨時構(gòu)建列為職業(yè)中最煩人的方面之一。 即使非常干凈地實施了ant或make build，遵循了本地化的最佳實踐，并且自動化了軟件生命周期的廣泛范圍，它仍然會用大量的原始數(shù)據(jù)（即腳本行）來懲罰新開發(fā)人員。 請注意，這只是臨時性 。 當然，這并不是敲響這些工具。 ant尤其擅長自動化任務(wù)并提供可重用的構(gòu)建小部件集。 但是，它無助于為構(gòu)建軟件的整個過程提供可重用的解決方案，因此，它也無助于新開發(fā)人員輕松理解其構(gòu)建過程。

對于像Maven這樣的CoC工具，最重要的約定是

因此，正如我所看到的，對于像Maven這樣的CoC工具，最重要的是約定。 為了成功使用Maven，您必須了解并遵循假定的約定。 不遵循約定的項目很快就會與Maven發(fā)生沖突。 首先，他們很難使用一種假定自己的構(gòu)建過程的工具來實現(xiàn)自己的構(gòu)建過程。 您很容易就無法輕松完成自己所做的事情而感到不安，但是前面的段落旨在表明實際上是您需要改變的人，至少在您打算繼續(xù)使用Maven的情況下。 選擇Maven時，您需要接受約定。 我不能，我建議您堅持使用Ant，它足夠靈活，可以按您的條件滿足您。 請記住，您正在失去利用Maven的設(shè)計模式方面來管理構(gòu)建復(fù)雜性的能力。 如果您認為自己的構(gòu)建沒有復(fù)雜性問題，請向自己提出以下問題：

• 我們團隊中的每個工程師都可以輕松構(gòu)建我們軟件系統(tǒng)的所有組件嗎？
• 我們的工程師有信心修改構(gòu)建腳本而不會感到焦慮嗎？
• 當需要有人解決構(gòu)建問題時，我們的工程師會逃離房間嗎？

因此，如果您到目前為止與我在一起，您可能會同意遵循Maven假定的慣例是進入Maven必殺技的關(guān)鍵先決條件。 這就是導(dǎo)致我得出Maven文檔糟糕的結(jié)論的原因。 它們不僅不足，而且可能有害。 他們大多記錄了配置，而根本沒有提到約定的關(guān)鍵主題。 我認為對配置的強調(diào)在很大程度上是偶然的，這使新手認為配置Maven是可以的，甚至是正常的。

Maven文檔不僅不足，而且可能有害。 它主要記錄了配置，而根本沒有提到約定的關(guān)鍵主題。

通過文檔，我主要是指訪問Maven或Codehaus插件頁面時發(fā)現(xiàn)的所有內(nèi)容。 例如，考慮極核心的maven-assembly-plugin。 瀏覽Maven網(wǎng)站上的文檔 ，您會發(fā)現(xiàn)它幾乎完全與配置有關(guān)。 正如我已經(jīng)陳述和重申的那樣，問題是您真的不想配置Maven。 您想遵循約定。 配置應(yīng)僅是最后的選擇。

插件放東西，然后下一個插件找不到那個東西。 使用配置文件告訴Maven在哪里可以找到東西，然后沒有該配置文件，其他任何人都找不到該東西。 配置Maven會使您陷入配置反饋循環(huán)中，并且配置的幾何增長不會使其具有pom可讀性。 即使可以通過配置Maven使Maven滿足您的需要，您也會很快得到一個難以理解的構(gòu)建。

使用配置更改一個插件放置東西的位置，然后下一個插件找不到該東西。

因此，請避免配置！ 相反，請遵循常規(guī)路徑。 您的工程師會知道并喜歡他們的構(gòu)建，并且您將輕松利用Maven生態(tài)系統(tǒng)提供的許多好處-從豐富的插件庫到存儲庫服務(wù)器和構(gòu)建服務(wù)器。

但是如何學習Maven約定呢？ 這全都與社區(qū)有關(guān)。 幸運的是，這是一個非常友好的社區(qū)。 這是我在嘗試確定應(yīng)如何在Maven中完成工作時使用的一些最重要的資源。

• Sonatype博客
• 堆棧溢出
• Maven用戶列表

此外，為了成為一個友好的社區(qū)成員，我正在使用此博客條目作為一系列Maven條目的介紹。 這些條目中的每一個都會概述重要的Maven約定。 我將詳細介紹約定并提供示例poms。 因此，如果您想了解Maven約定，請保持聯(lián)系。

參考： Maven不吸。 。 。 但是我們的W4G合作伙伴 Chad Davis 的Maven Docs Do來自zeroInsertionForce博客。

翻譯自: https://www.javacodegeeks.com/2012/04/maven-does-not-suck-but-maven-docs-do.html

總結(jié)

以上是生活随笔為你收集整理的Maven不会吮吸。 。 。 但是Maven文件会的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。