#
摘要: ivy綁定一些默認設置，這使得在通常環境下使用ivy很容易。這個教程，接近于參考文檔，解釋這些默認設置是什么和他們怎樣調整來滿足你的需要。
為了完整的理解設置的概念和你可以用它們做什么，我們建議閱讀其他和設置相關的教程(如Multiple Resolvers 和 Dual Resolver)或者設置文件的參考文檔。
閱讀全文
摘要: 在這個例子中，我們將看到使用ivy的一個最簡單的方式。不使用任何特殊設置，ivy將使用maven2 倉庫來解析你在ivy文件中聲明的依賴。讓我們來看一眼涉及到的文件的內容。
你將在ivy發行包的src/example/hello-ivy 目錄下找到這個教程的源文件。
閱讀全文
摘要: 學習的最佳方式是實踐！這是ivy教程將幫助你做到的，發現一些偉大的ivy特性。
這里是非常優先的教程，它甚至不需要安裝ivy，如果你已經正確安裝了ant和jdk，甚至只需要花費不到30秒的時間
閱讀全文
摘要: 在ivy中有幾個任務被認為是后解析任務(post resolve task)，并相應地共享公用行為和設置。
這些任務是：
* retrieve
* cachefileset
* cachepath
* artifactproperty (since 2.0)
* artifactreport (since 2.0)
閱讀全文
摘要: cachefileset,為配置構建一個有ivy緩存中的制品組成的ant fileset 從1.2版本起)。
這是一個后解析任務，有所有后解析任務共有的所有行為和屬性。注意這個任務不依賴retrieve，因為構建的fileset是由ivy緩存中的制品直接構成的。
閱讀全文
摘要: ln命令用于連接文件或目錄,lndir命令用于創建目錄的符號鏈接，和ln不同的是lndir會自動為源文件目錄下所有的文件和子目錄都建立對應的符號鏈接.
閱讀全文
摘要: find命令用于查找文件和目錄，任何位于參數之前的字符串都將被視為欲查找的目錄。
find 可以指定查找條件如名稱，類型，時間，文件大小，權限和所有者查找，針對多個條件進行與或非的邏輯運算。我們可以控制find的查找的行為，還可以和其他命令組合使用。
閱讀全文
摘要: 為解析過的模塊配置構建一個由在ivy 緩存(或者取決于useOrigin 設置的原始位置)中的制品組成的ant path.
閱讀全文
摘要: ls的用法: ls [OPTION]... [FILE]...
列舉文件信息(默認當前目錄), 如果-cftuvSUX或者--sort沒有設置則按照字典順序排序條目。
閱讀全文
摘要: 交付當前模塊的解析好的描述符，而且可能執行依賴的遞歸交付。
這個任務主要做兩個事情：
1. 生成一個解析好的ivy 文件
2. 執行遞歸交付
閱讀全文
工作中發現的一個非常奇怪也很有趣事情，有關MANIFEST.MF文件中的分行和空格的格式要求，分享給大家。
對于通常的MANIFEST.MF文件，一般格式是：
Class-Path: lib/a.jar lib/b.jar lib/c.jar lib/d.jar lib/e.jar lib/f.jar
在一行之內將所有的jar包路徑寫上，空格分隔即可。
但是對于一些大型的項目，因為依賴包眾多，比如大于30個，那么如果還寫在一行內，就會出現一個長度驚人的行。程序運行倒不會有任何問題，但是對于版本控制就很不友好，如增加或者減少一個依賴包，這行就會被改寫。以后compare不同版本時，只能知道這行被修改了確無法直接知道是做了什么修改，必須通過其他方式才能對比出來。
同樣的問題發生在code merge時，如果兩個分支都修改了這個文件，就必須通過手工來進行merge，而且要對照出來彼此到底改了什么，很困難而且容易出錯。
因此一個改進就是將這個文件中的依賴按照一行一個依賴的方式重寫，這樣以后修改時只會修改改依賴所在的行，很容易就對比出來具體做了哪些感動，code merge時版本控制軟件一般也很容易直接自動merge成功。
修改后的文件類似如下：
Class-Path: lib/a.jar
lib/b.jar
lib/c.jar
lib/d.jar
lib/e.jar
lib/f.jar
但是在實際操作時發生了意料之外的問題，會出現異常或者類無法找到，經檢查發現問題出現在MANIFEST.MF的格式上，MANIFEST.MF對于分行和空格是有特殊要求的：
1. 每行的最后一個jar的名稱后不容許有空格
即" lib/b.jar"在b.jar后必須回車結束本行，不能有空格，一個都不能
2. 每行的開頭必須有不少于2個空格
即" lib/b.jar"在b.jar前必須有不下兩個空格
以上兩個條件有一個不滿足都會出現問題，有點古怪。
摘要: 發行當前模塊的制品和已解析的描述符(已交付的ivy文件)。
這個任務的目的是發行當前模塊描述符和它的聲明的發行制品到倉庫中。
閱讀全文
摘要: configure任務用于通過xml設置文件來配置ivy。
閱讀全文
摘要: retrieve任務復制解析好的依賴到你的文件系統的任何位置。
這是一個post resolve任務，帶有所有post resolve任務共有的所有的行為和屬性。
閱讀全文
摘要: 解析任務實際解析在ivy文件中描述的依賴，并將解析后的依賴放置到ivy緩存中。
如果在resolve任務前沒有調用configure任務，則將使用默認的configuration (等同于不帶參數的調用configure).
閱讀全文
摘要: buildlist任務用于獲取按照ivy依賴信息從小到大排序的文件(通常是build.xml文件) 列表，或者相反(從1.2之后)
這個任務在結合subant構建相關項目集合時特別有效, 可以確保依賴在其他依賴它的模塊之前被構建
閱讀全文
摘要: 轉一個blog，關于如何使用ivy來處理native的依賴，對于有使用JNI開發的朋友應該很有價值。
原文blog地址：http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy/
閱讀全文
我們的團隊一直埋怨說我們的代碼規模太大，結構太復雜，維護難度大而成本高。
最明顯的一個弊病，就是在clearcase里面打開一個文件的version tree，密密麻麻，橫七豎八，我們戲稱為"蜘蛛網"。
然而昨天一位出差在外的同事，在維護公司另外一個產品的時候，有了驚喜發現：
我們的代碼規模比起來還是差得遠！
有圖為證：
我的評價只有一個字：
暈!
PS:
解釋一下，有些朋友沒有用過版本控制軟件的version tree，可能不大明白。
這個是version tree，是一個文件(注意，只是一個文件)的版本和分支歷史，一般的版本控制軟件都會提供類似的視圖。
圖上藍色直線條的是這個文件的不同分支和這個這個分支下的不同版本，紅色的線條是code merge，就是從一個分支的某個版本merge 代碼到另外一個分支上時為了表示這種merge關系而增加一種表示方式。
從圖上看，這個文件的分支過百了，版本應該過千，紅色的merge線在某些地方已經要凝成實體了。這表明在這些版本之間有非常頻繁的code merge。
再補充一下：
這個圖片里面有些地方紅線密集程度有些不大對勁，某些分支幾乎每個版本修改都有被merge。正常開發中不應該是這樣的，通常都只會是某個或某幾個版本被merge。
猜測出現這個情況的可能，有一種解釋就是可能在開發時使用了某些自動merge的工具，當該分支每出現一個新版本時就自動merge到某個目標分支，以保證兩個分支代碼的高度一致。當然這個無法證實，只是我的一個猜測。
摘要: 這個是發生在上周周末的真實案例，因為cxf client 端線程安全導致的錯誤，總結出來希望其他使用cxf的朋友注意。
閱讀全文
摘要: ivy可以非常容易的作為一個單獨的程序使用。你所需要的只是一個java1.4+的運行環境(JRE)!
閱讀全文