小張是一家小型民營軟件公司的程序員，他所在的公司要開發一個新的Web項目。經過協商，決定使用Spring、iBatis和Tapstry。jar包去哪裡找呢？公司裡估計沒有人能把Spring、iBatis和Tapstry所使用的jar包一個不少地找出來。大家的做法是，先到Spring的站點上去找一個spring-with-dependencies，然後去iBatis的網站上把所有列出來的jar包下載下來，對Tapstry、Apache commons等執行同樣的操作。項目還沒有開始，WEB-INF/lib下已經有近百個jar包了，帶版本號的、不帶版本號的、有用的、沒用的、相衝突的，怎一個「亂」字了得！
在項目開發過程中，小張不時地發現版本錯誤和版本衝突問題，他只能硬著頭皮逐一解決。項目開發到一半，經理發現最終部署的應用的體積實在太大了，要求小張去掉一些沒用的jar包，於是小張只能加班加點地一個個刪……
小張隱隱地覺得這些依賴需要一個框架或者系統來進行管理。
小張喜歡學習流行的技術，前幾年Ant十分流行，他學了，並成為了公司這方面的專家。小張知道，Ant打包，無非就是創建目錄，複製文件，編譯源代碼，使用一堆任務，如copydir、fileset、classpath、ref、target，然後再jar、zip、war，打包就成功了。
項目經理發話了：「兄弟們，新項目來了，小張，你來寫Ant腳本！」
「是，保證完成任務！」接著，小張繼續創建一個新的XML文件。target clean；target compile；target jar；……不知道他是否想過，在他寫的這麼多的Ant腳本中，有多少是重複勞動，有多少代碼會在一個又一個項目中重現。既然都差不多，有些甚至完全相同，為什麼每次都要重新編寫？
終於有一天，小張意識到了這個問題，想復用Ant腳本，於是在開會時他說：「以後就都用我這個規範的Ant腳本吧，新的項目只要遵循我定義的目錄結構就可以了。」經理聽後覺得很有道理：「嗯，確實是個進步。」
這時新來的研究生發言了：「經理，用Maven吧，這個在開源社區很流行，比Ant更方便。」小張一聽很驚訝，Maven真比自己的「規範化Ant」強大？其實他不知道自己只是在重新發明輪子，Maven已經有一大把現成的插件，全世界都在用，你自己不用寫任何代碼！
為什麼沒有人說「我自己寫的代碼最靈活，所以我不用Spring，我自己實現IoC；我不用Hibernate，我自己封裝JDBC」？