Life|35岁前应该做好的几件事！

35岁前应该做好的几件事！ - 尚德 - 6PARK.COM BLOG

35岁前应该做好的几件事！

作者: 尚德   发表日期: 2010-01-25 06:28   复制博文链接

  人不能失去自我，不管时空如何变化，人不能随潮流改变自己，不能失去了自我。我们应该追求自己喜欢的事情，关于爱情、婚姻也罢，这只是生活中不能缺少的，但并不能是生活的全部，有人曾说“30岁前是个人发展的最好的时间，不能错过。除了家庭外，工作更是我们生活的意义”。----的确，除了我们需要全心付出的感情外，还有很多美好的东西需要追求。

  很多成功的人中，感觉他们有三点共性：生活简单，不拘泥于生活中的小节；注重亲情友情；对工作孜孜以求、精益求精。这样在生活中生活得轻松愉快，工作中能以饱满的精力投入自己的工作。
“不管你以后是科学家、官员、记者，你永远是你”。人不能失去自我，应该选择自己喜欢的事情并用自己喜欢的方式去做，培养自己的个性，但是需要强调的是，成功的个性是使得你更加的富有吸引力和与人和谐相处，而不是让人对你敬而远之，如果那样的话，就不是个性而是活的失败。

　　下面谈一谈在中年之前，我们应该实现的目标和理想以及十分要注意的。

  35岁是青春的后期，35岁以后是收获的季节，如果你没有资格说这句话，你将会憎恨自己。所以在35岁以前，在烂漫蓬勃的青春年华里，最好把下面十件事做好：
　　　　
　　第一，学会本行业所需要的一切知识并有所发展。
　　　　
　　已故零件大王布鲁丹在他35岁时，已经成为零件行业的领袖，并且组建了年收入达千万美元的海湾与西部工业公司。每个人在年轻时都可能有过彻夜不眠、刻苦攻读，这在20岁甚或30岁都没有问题，但到了35岁，就不应该再为学习基本技能而大伤脑筋了。35岁之前是一个人从事原始积累的阶段，35岁之后就应该勃发了。
　　　　
  第二，养成个人风格。
　　　　
　　在35岁以前，找出你所喜欢的，不论是衣着或是爱好，哪怕是与众不同的小习惯也好。20岁、30岁时你可以不断尝试、不断改变，但是到了35岁，你便要明确地建立个人风格。一位男士或女士在事业中途改变自己的形象，就会让人觉得很不可靠。你喜欢穿西装吗？好！就把西装当作你的商标吧！办公桌上摆些鲜花会令你工作更有效率吗？那就每天都摆些鲜花吧！
　　　　
　　第三，在感情生活方面平和安定。
　　　　
　　在攀登事业的高峰时，如果私人生活不愉快，陷入感情危机，对你会产生很大的干扰，甚至会逐渐令你对别的事物失去兴趣。那些在35岁之前私人生活已经平和安定的人，一般都比生活动荡不安的人有更大的机会获得成功。因此，如果你想结束一段没有结果的恋情，或者你想和女友结婚，那就赶快行动吧，免得把问题拖到生命的第35个春秋。在35岁以后，你应该专注地看着你对事业的投资开始获利。
　　　　
　　第四，明白自己的短处。
　　　　
　　承认有些事情你的确做不好，或者不愿做。如果你讨厌数字而喜欢创作，那就不要因为待遇高或顺从别人的期望而强迫自己做数字工作。在35岁之前，一定要投入你所喜爱、所擅长的那种工作。否则，35岁之后必然会有一段郁郁不乐的日子。而且，真正的成功可能因为活力的消退而丧失。
　　　　
　　第五，知道自己的长处。
　　　
　　你应该知道自己擅长什么，并且清楚你所喜欢做而又做得比别人好的事情。不管你目前担任什么样的角色，知道自己的长处对成功都很重要。
　　　　
　　第六，储备辞职另谋生路的钱。
　　　　
　　在这个多变的职业世界里，你也许不会永远在一个地方工作，或者永远在一个位置上淋漓尽致地发挥自己，当你感到无法施展时，你很可能会想到辞职，或者开辟第二职业，如果你事先储蓄了足够的钱，你便有了一个安全的后盾。
　　　　
　　第七，建立人际关系网。
　　　　
　　如果到了35岁你仍未建立起牢固的人际关系网，那你就有麻烦了。这个人际关系网包括你的朋友、亲人，最低限度包括所有可以互相帮助的人。这些人有的是你的同事，有的受过你的恩惠，有的你倾听过他们的问题，有的你和他有着相同的爱好。人际关系网不是一朝一夕就能建立起来的，它需要几年甚至十几年的培养。一个人在事业上、生活上的成功其实如同一个政党的成功，你要有许多人散布在适当的地方，你可以依赖他们，他们也可以依赖你。
　　　　
　　第八，学会授权他人。
　　　　
　　许多人不肯或不能这样做，因此始终被钉在从属的职位上。授权他人是成功的一半，一个事无巨细，不能将工作授权别人的人，注定会遇到极大的障碍。到了35岁，你最好已成为这方面的专家。换言之，你懂得挑选合适的人并信任他们。
　　　　
　　第九，学会在什么时候三缄其口。
　　　　
　　因说话不小心而自毁前程的人，比因为任何其他原因丧失成功的人都多。要学会保持沉默而且看起来机智--别人自然以为你知道的比实际还多。别讲别人的闲话，别谈论你自己的大计，守口如瓶所赢得的声誉，远比讲人闲话所带来的东西更加珍贵。你在事业上越成功，这一点就越重要。
　　　　
　　第十，对人要忠诚。
　　　　
　　如果你到了35岁仍未能建立起坚如磐石的忠诚信誉，这一缺点将会困扰你一生。不忠诚的恶名必然会使你在事业上到处不受欢迎。你不能靠暗箭伤人爬到事业的顶峰，而要靠在早期树立起来的真诚刚直和不可动摇的声誉。35岁以前，忠诚只是投资；35岁以后，你会作为一个可以信赖的人收到忠诚的回报。 　

Design|UML2.0工具比較

UML2.0工具比較 - 旅途 - CSDN博客

UML2.0工具比較 收藏

「工欲善其事，必先利其器」，學習UML沒有好的工具幫忙，往往會讓開發人員半途而廢，尤有甚者，開發人員有時會因為使用了不容易使用的開發工具而誤認為UML是一個非常困難學習的「技術」。殊不知UML只是一種「語言」，就和學習中文、美語一樣，學習UML根本不困難，只要瞭解UML的語法以及知道UML的適用時機，UML自然手到擒來。當然，如果有一套上手的UML開發工具，UML的困難度更是大幅降低，這也是本次專欄我們會討論UML工具評比的原因。

在這次專欄中，我們將評比三個不同的UML工具 – IBM公司的 Rational Software Architect(以下簡稱RSA)、Borland公司的 Together Architect(以下簡稱Together)以及Sparx Systems公司的 Enterprise Architect Corporation Edition(以下簡稱EA)。
評比的標準會從以下兩個面向來分別評估：

1. 對UML 2.0的支持；
2. 文件產生機制。

整篇文章中，我們會分成兩大部分，主要針對這三套軟體在上述的兩個面向中的操作進行說明，並且在每一個部分的最後一個小節，都會對三個軟件在該項目中做綜合評比。
不過在開始介紹之前，先就價錢做個評比說明，根據三家公司的產品標準售價，其價格的比較表如下表：

公司	產品	價格(美金)
IBM	Rational Software Architect	5500
Borland	Together for Eclipse Architect Edition	5000
Sparx Systems	Enterprise Architect Corporate Edition	239

表1：三套軟件的價格表

對！不要懷疑，這三個產品的價格的差距大約是20倍。先有這樣的一個印象後，我們將針對這三個產品的功能再詳細介紹。

對UML 2.0的支持分析

圖1 是OMG所定義的UML十三張圖的分類(參考自Unified Modeling Language: Superstructure, Version 2, p. 660)。

圖1、UML 2.0 規範的 Diagram 分類

以下，我們將針對上述的三個軟件分別說明其對於UML 2.0規範的十三張圖的支援。

1、IBM RSA：

IBM的 RSA 與 Borland Together都是建構在 Eclipse 平台上，因此，你必須要先建立一個 UML 2.0 的專案，如此才可以繪製UML的圖形。下圖2就是 RSA 的 UML專案的操作畫面。

圖2、RSA 的 UML 2.0 專案操作畫面

和 Eclipse 的操作相類似，在 RSA 的操作畫面中，左邊是專案區，右邊則是所有可以使用的工具區。

在 RSA 中可以新增的圖形共有：Class Diagram、Composite Structure Diagram、Component Diagram、Deployment Diagram、Use Case Diagram、Activity Diagram、State Machine Diagram、Sequence Diagram以及Communication Diagram等九張圖。

比較起 UML 2.0 的規格所制訂的十三張圖，分別少了 Object Diagram、Package Diagram、Interaction Overview Diagram 以及 Timing Diagram 四張圖。
不過如果我們詳細觀看 UML 2.0 的規格，我們可以發現，其實 Object Diagram 與 Package Diagram 的基本 Diagram 其實就是 Class Diagram，只是在這兩張圖中，其分別表達了 Package 間的相依關係以及 Object 之間的關係。因此，在 RSA 中，我們可以使用 Class Diagram 來繪製這兩張圖形。

至於 Interaction Overview Diagram也是類似的狀況，在 UML 2.0 的規格中，其基本的圖形是 Activity Diagram，因此，我們同樣也可以利用 Activity Diagram 來繪製 Interaction Overview Diagram。

至於時序圖，雖然在 RSA 中的 Communication Diagram 可以表達時序圖中的LifeLine，但是其餘的相關的UML元件都缺乏，因此，RSA並無法完整表達時序圖。

就以上的說明我們可以瞭解，要在 RSA 中繪製完整的十三張 UML 2.0 規範的圖形，其實有一點困難性，開發人員必須要很清楚地知道這十三張圖各自的主要特性，如此才可以找到適當的圖形來進行繪製。

至於操作性上，開發人員如果熟悉 Eclipse 的介面的話，使用 RSA 算是還相當簡易，但如果不幸地，開發人員使用的 IDE 工具是 Eclipse 以外的開發工具的話，使用 RSA 算是有些難度在的。

接著來看細部的操作，在RSA中，開發人員可以輕易地將繪製好的 Sequence Diagram 轉成 Communication Diagram，反之亦然，這算是 RSA 延續過往 Rose 的重要特性，可以說是這套產品最讓人激賞的部分。

最後談到 MDA(Model-Driven Architecture)的機制，在 RSA 中提供三種轉換機制，分別是 UML->Java、UML->C++以及UML->EJB，由於 RSA 是建置在 Eclipse 上，因此，其轉換為 Java 或 EJB 時，能夠非常順暢地跟 Eclipse 的 Java 或是 J2EE 專案結合，在這個部分，也是 RSA 一向的強項。

2、Borland 的 Together：

跟 RSA 相同，在 Borland Together 中要新增 UML 2.0 的Diagram，也必須要在Eclipse的環境中新增一個 UML 2.0 的專案。下圖3即是 Borland Together 的操作畫面。

圖3、Borland Together 的操作畫面

跟 RSA 不同，Borland Together 儘可能地讓操作介面與先前的版本類似。針對每一張不同類型的 UML Diagram，其所可以使用的工具都不同，該工具列如上圖右方的「Pallets」繪圖模版。

另外跟 RSA 類似的，則是在 Borland Together 中，同樣地也只支持 UML 2.0中的九張圖(如上圖左方框起來的部分)，Package Diagram、Object Diagram、Interaction Overview Diagram 以及 Timing Diagram 都不能直接由 Borland Together 中選取。

如同前面所說，Package Diagram 以及 Object Diagram 都可以使用 Class Diagram 來繪製，相同地，在 Borland Together 中你也可以利用 Class Diagram 來繪製這兩張圖。

至於 Interaction Overview Diagram 以及 Timing Diagram，則在 Borland Together 中並沒有辦法繪製。

大體而言，Borland Together 在 UML 2.0 的支持上主要是缺少了上述的兩張圖；再就實際的操作來說，Borland Together 延續了過往 Together 的操作方式，因此，對於Together舊有的用戶來說，不會造成太大的困擾。

此外，Together 在 Sequence Diagram 與 Communication Diagram 的互轉上，提供一個很有趣的機制，就是你可以根據一張相同的 Interaction Diagram，指定利用「Sequence Diagram」或是「Communication Diagram」來呈現，這是一個非常有趣的想法，更體現了這兩張圖是同一個實作的不同觀點的這個看法。

至於若要根據 UML 產生 Source Code，則必須要採用不同的專案。如果要產生 Java 的程式碼，必須要選用「Java Modeling」專案，此時，當你在該專案中建立 Class 時，Together都會自動產生一個 Java Class，當該 Class 的屬性或是操作有所變動時，則會立刻反應到程式中。這一點和先前的 TogetherJ 是完全相同的。

此外，Together 仍然保有過去 TogetherJ 的重要功能，也就是可以利用 Sequence Diagram 產生 Implement 的程式碼，相同地，也可以由程式碼反轉回 Sequence Diagram。這算是 Together 的一大特點，也是其與其他兩個產品競爭的最大優勢。

3、Sparx Systems 的 EA(Enterprise Architect)

EA 是這三個軟件中最輕薄短小的。由於採用 Stand-alone 的 AP，因此安裝 EA 時不需要先安裝 JRE 及 Eclipse。

至於在 EA 中繪製 UML Diagram，則相對簡單的多，由於 EA 本身就是繪製 UML 的工具，因此，你只要在 EA 中新增一個專案，其自然就會把所有 UML Diagram 要繪製的相關環境準備好。下圖4就是 EA 的設計環境。

圖4、EA 的操作畫面

和 Eclipse 的操作相類似，在 RSA 的操作畫面中，左邊是專案區，右邊則是所有可以使用的工具區。

EA 的操作介面和前面的兩個軟件有相當大的不同。最主要的原因是前面兩個軟件都是建構在 Eclipse 的基礎下，因此，其基本的操作會受到 Eclipse 的影響；而 EA 本身則是一個獨立的程式，因此，其操作的方式自然可以自行去設計。

如果開發人員熟悉像 Delphi、Visual Studio 或是 Borland 等IDE開發工具的話，會發現EA的操作環境和這些工具非常類似。在整個開發環境中，右方是工具區，左方則是整個Project相關的各種不同的視界(View)。

在 EA 中，所有的 UML 圖形將會放置在 Project View 中。和 Togethe r類似的，當你指定到一個特定 Type 的 Diagram 時，左方的 Toolbox 會停留在該 Diagram 對應的 Pallet 上，這在操作上是非常方便的。

接著看到對 UML 2.0 的支持上。相同地，你可以看到圖4中央框起來的對話框，那就是在 EA 中可以支持的 UML 2.0的Diagram。

除了 RSA 及 Together 所支持的那九張 Diagram 外，EA 另外也支持剩餘的四張 Diagram；除此之外，EA也另外支持非標準的 Analysis Diagram(Eriksson-Penker Business Extensions，台灣俗稱魚骨圖)。因此，若單從對 UML 2.0 的支持來說，EA算是最完整支持UML 2.0的工具。

不可避免地，我們也必須要談到 EA 中對於 Sequence Diagram 與 Communication Diagram 的互轉，這方面 EA 並沒有提供任何的功能允許這兩張圖彼此互轉，這算是EA中比較弱的一環。

接著看到 EA 對於 MDA 的支持。在 EA 中，這個部分做的非常彈性，開發人員可以利用 Script 的語法自行定義自己的 Transformation Rule。在 EA 中則提供 C#、EJB、Java、DDL、XSD 以及 Web Service等標準的轉換機制，讓開發人員可以將同一個 PIM(Platform-Independent Model) 的 Model 轉換為各種不同平台的 PSM(Platform-Speficic Model)。

至於程式的雙向工程，EA 則支持了包括 C#、VB、VB .NET、Java、C++、Delphi 及 PHP 等各種不同的程式語言。就單一產品而言，在程式語言的支持度上，EA 算是這三個工具之中最多元的 (RSA只支持Java及C++；Together只支持Java)。

至於和 IDE 工具的整合上，由於 EA 是一套 Stand-alone 的應用程式，因此在對於 IDE 工具的支持上不如 RSA 與 Together。

對UML 2.0支持的綜合評比：

有關這三套軟件在 UML 2.0 的支持上，我們將以下表2 來進行分析。

項目	RSA	Together	EA
對UML 2.0十三張Diagram的支持	不支持Timing Diagram	不支持Timing Diagram、Interaction Overview Diagram	支持十三張Diagram
Sequence Diagram與Communication Diagram的互轉機制	提供	提供	不提供
MDA機制	有	有	有
支持的程式語言	兩種	兩種	九種
Sequence Diagram轉換為程式碼	有	有	沒有
對於IDE介面的整合度	高	高	低

表2、對 UML 2.0 的支持分析

 

文件產生機制(Document Generator) 比較

對於開發人員來說，繪製設計圖以及進行程式寫作並非最繁重的工作，因為這是身為一個軟體開發人員勢必要做的事，但是，要將軟體的設計圖以及程式碼製作成開發的文件，往往會造成開發人員的重大困擾。這並不是因為這些文件不重要，或是開發人員不重視，而是因為要在設計工作進行的過程中，隨時去注意文件的格式或是內容，往往會讓設計人員的思緒受到影響。正因為如此，使用一個好的UML工具，幫助開發人員能夠利用工具產生開發文件的功能，才會成為評估UML 工具是否合格的重要評斷標準。那麼，究竟要如何才能夠評估一個UML工具是否有足夠的能力產生開發文件呢？大致可以從以下幾個部分來進行評估：

• 文件所能夠支援的格式有多少？
• 是否可以客製化為開發團隊所適用的格式？
• 製作文件所需要花費的Effort有多少？

以下我們將針對這幾個部分，分別來探討。

1、IBM RSA：

RSA 基本上與 Rose 相當類似，其所能夠支持的文件類型相當有限，主要是 PDF 與 HTML，下圖5即是 RSA 產生文件的操作畫面(以產生 PDF 為例)。

圖5、RSA 產生設計文件的操作畫面

基本上，RSA 所能夠產生的相關設計文件其實也只有兩種，同時，開發人員也不能夠直接去建立該設計文件的 Template，因此，RSA 在設計文件的支持上是非常薄弱的。

在 RSA 的前一個版本中，IBM提供另外一個產生開發文件的工具 – Rational soDa，但是該產品最後發佈的版本是在 RSA Release 之前，因此，該版本是否有支持 RSA 仍在未定之天。不過單就 RSA 而言，其產生開發文件的功能實在是過於陽春，這是不爭的事實。

2、Borland Together：

延續上一個版本的特色，Borland Together 在製作開發文件上仍是相當簡便。其主要仍是利用 Template 的方式來產生文件。下圖6即是 Together 產生開發文件的操作畫面。

圖6、Together 的產生開發文件的操作畫面

而 Together 在產生文件的機制中，最讓人激賞的是其可以產生的文件格式多達五種，除此之外，其 Template 的設計也非常具備彈性，下圖7即是 Together 製作 Document Template 的製作畫面。

圖7、Together 的 Document Template 製作畫面

開發團隊除了使用 Together 所提供的 Template 之外，也可以依據團隊的需要自行製作自己的 Template，這在整個文件製作的彈性上，可說是非常完整。當然，針對之前的 Togethe r開發團隊來說，新版的 Togethe r仍然可以使用舊版所設計的 Template，在這一點上，Together 也勝過 RSA 許多。

3、Sparx Systems的EA：

EA所能夠製作的文件型態，主要是 HTML 與 RTF 格式。下圖即是 EA 的 RTF 開發文件的產生畫面。

圖8、EA 文件製作的操作畫面

EA 製作文件的方式和 Together 非常類似，也是利用 Template 的方式來產生文件，不過不同的是 Sparx Systems 發揮他們的特色，提供了多種預設的 Template，讓開發人員一方面可以直接使用這些 Template，另一方面也可以透過 Copy Template 的方式來製作自己的 Template，下圖9即是透過 EA 的預設 Template 所製作的某個開發團隊的 Template 的設計畫面。

圖9、EA 的 Template 製作畫面

相同地，EA 的最大特色就是簡單。因此，EA 的 Document Template 所採用的設計方式是「WYSWYG」(What You See is What You Get) 的方式，對於開發人員來說，利用這種方式來進行設計，會相對簡單許多。不過與 Togethe r提供多種的 Document Type 相比，EA所提供的 Document Type 就陽春的多。

文件製作的綜合評比：

相同地，我們利用前面所說的三個重點來對這三個工具做一個評比，評比的結果如表3。

項目	RSA	Together	EA
文件所能夠支援的格式	PDF、HTML	RTF、PDF、HTML、TXT	RTF、HTML
是否可以客製化為開發團隊所適用的格式	不能	可以	可以
製作文件所需要花費的Effort有多少	簡單，但不能設計自己的文件Template	簡單，但設計文件Template較為困難	簡單，設計文件Template難度中等

表3、對於文件製作的綜合評比

 

結論：

本文的目的主要是希望讀者能夠透過筆者對於這三套軟件實際操作後的心得，瞭解這三套軟件各自的優缺點，並且能夠根據讀者各自的需要，透過成本-效益的分析，選擇一套最適合自己開發團隊的UML工具。

事實上，除了上述的幾個面向外，讀者在實際選擇UML工具時，仍應該考慮以下幾個不同的面向，包括：專案管理上的難易度、團隊開發平台的支持、需求蒐集的面向以及測試機制的支持….等。不過由於篇幅的關係，我們只能夠把此次的主題放在「UML 2.0的支持」以及「文件製作的機制」上。

Design|Implementing State Pattern in Java

Implementing State Pattern in Java

In the previous post, I described a little about the State design pattern and it's relation to the Strategy pattern. In this post, I will show how to implement the State Pattern in Java. The following is the UML diagram for the State Pattern. A description and sample code for the example follows:

• Context: Acts as the interface to clients. The Context object maintains an instance of a ConcreteState subclass that represents the current state. The context delegates the requests to the concrete state object that represents the current state. Typically, the context passes itself as an argument to the current state object, which changes the current state of the context.

  public class StateContext {
   private State acceptedState;
   private State requestedState;
   private State grantedState;
  
   private State state;
  
   public StateContext() {
     acceptedState = new AcceptedState();
      requestedState = new RequestedState();
     grantedState = new GrantedState();
     state = null;
   }
  
   public void acceptApplication() {
     this.state = acceptedState;
   }
  
   public void requestPermission() {
      state.requestPermission(this);
   }
  
   public void grantPermission() {
     state.grantPermission(this);
   }
  
   public String getStatus() {
     return state.getStatus();
   }
  
   public void setState(State state) {
      this.state = state;
   }
  
   public State getAcceptedState() {
     return acceptedState;
   }
  
   public State getGrantedState() {
     return grantedState;
   }
  
   public State getRequestedState() {
      return requestedState;
   }
  
  }
  

  StateContext.java
• State: An interface for encapsulating the behavior associated with a particular state of the Context.

   public interface State {
   public void grantPermission(StateContext ctx);
   public void requestPermission(StateContext ctx);
   public String getStatus();
  }

  State.java
• Concrete State subclasses: Define the behaviour associated each state.

   public class RequestedState implements State {
   public void grantPermission(StateContext ctx) {
     System.out.println("Granting Permission");
     ctx.setState(ctx.getGrantedState());
   }
   public void requestPermission(StateContext ctx){
      System.out.println("Permission already requested");
   }
   public String getStatus() {
     return "Requested permission";
   }
  }

  RequestedState.java

  public class AcceptedState implements State {
    public void grantPermission(StateContext ctx) {
    
   }
   public void requestPermission(StateContext ctx){
     System.out.println("Requesting permission");
     ctx.setState(ctx.getRequestedState());
    }
  
   public String getStatus() {
     return "Request Received";
   }
  }

  AcceptedState.java

  public class GrantedState implements State {
   public void grantPermission(StateContext ctx) {
     System.out.println("Invalid state");
   }
   public void requestPermission(StateContext ctx){
    System.out.println("Invalid state");
   }
   
   public String getStatus() {
    return "Granted";
    }
  }

  GrantedState.java
• Client

  public class StateClient {
   public static void main(String[]args) {
     StateContext ctx = new StateContext();
      ctx.acceptApplication();
     ctx.requestPermission();
     ctx.grantPermission();
     System.out.println(ctx.getStatus());
   }
  }

  StateClient.java

OZ|最佳生活质量国家排名：法国6年第一 澳洲第二

最佳生活质量国家排名：法国6年第一 澳洲第二(图) -6park.com

最佳生活质量国家排名：法国6年第一 澳洲第二(图)

新闻来源: 网络社区 于January 08, 2010 19:13:05 敬请注意:新闻取自各大新闻媒体，观点内容并不代表本网立场！

以"生活简单但美好"为标准来评定的生活质量最佳的国家排名中，澳大利亚在194个国家中的排名上升至第二位。 www.6park.com

《国际生活》杂志（International Living magazine）每年一月都会对国家的生活质量进行排名和评级，以便让读者了解生活质量最佳的国家和地方。 www.6park.com

"这并不是一个绝对值，我们的标准是生活简单但美好，"该杂志称。 www.6park.com

澳大利亚落后于过去五年来一直排名首位的法国位列第二，瑞士、德国和新西兰分列三、四、五位。不过英国还落后于捷克、立陶宛和匈牙利，排名第25位。 www.6park.com

www.6park.com

该杂志高度称赞澳大利亚为一个适合居住的国家。"他们把澳洲称为幸运之国不是没有原因的。澳大利亚因广阔的海滩和温带气候而出名。在整个澳洲大陆，澳人和那些选择移居至此的人们都获得了积极而健康的生活方式。但城市居民会发现在悉尼和墨尔本有许多伟大的文化和美食，而生活成本却低于世界其他一些大城市，"《国际生活》杂志说。 www.6park.com

"澳大利亚比任何其他西方国家都更好的处理了全球金融危机带来的影响。对于游客和旅行者来说，这意味着他们将面对澳元的强劲，在澳旅游将变得更贵。不过如果你打算留在澳洲，你会发现很少像澳洲那样拥有高质量卫生服务和基础设施建设的英语国家会从亚洲和中国的经济繁荣中获益。" www.6park.com

"澳洲经济主要依靠向工业化人口迅速扩张的亚洲国家出口农业、矿业和能源。从全球标准来看，澳洲的房产仍然保持着昂贵的水平，但对于那些移居国外的技术工人来说，有很的就业机会等待着他们。" www.6park.com

《国际生活》杂志的排名评定根据9个方面的因素：生活成本、文化和休闲、经济、环境、自由、健康、基础设施、安全和危险，以及气候条件。

Design|从追MM谈Java的23种设计模式

2009年11月11日 随笔档案 - kangdy - BlogJava

从追MM谈Java的23种设计模式
设计模式做为程序员的“内功心法”，越来越受到.net 社区的重视，这种变化是很可喜的，Java社区走在了我们的前面，但这种状况也许有一天会发生改变。

　　从追MM谈Java的23种设计模式

　　1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯 德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory.

　　　　工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点 是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

　　程序代码

　　以下是引用片段：

以下是引用片段：
public class Factory{
　　　　　　public String Boy = "boy" ;
　　　　 　　public String Girl = "girl" ;
　　　　　　public People getPeople (String people){
　　　　　　　　if (people.equals("boy")){
　　　　　　　　　　return new Boy();
　　　　　　　　}else if(people.equals("girl")){
　　　　　　　　　　return new Girl();
　　　　　 　　　}
　　　　　　}
　　　　}

　　2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖)

　　 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得 产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

　　3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模 式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

　　　　工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出 具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

　　4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是 我的情话prototype了。(100块钱一份，你要不要)

　　原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

        5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个 人，那就是我(刚才做了个梦啦，哪有这么好的事)

　　　　单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的 “单一实例”的需求时才可使用。

　　以下是引用片段：

以下是引用片段：
　　　　public　class SingLeton{
　　　　　　private static SingLeton instance = new SingLeton();
　　　　　　public static SingLeton getInstance(){
　　　　　　　　return instance;
　　　　　　}
　　　　}

　　6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他 作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)

　　　　适配器(变压器)模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类 能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

　　7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好; 碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型， 要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了

　　桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的 抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

　　8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有?

　　　　合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成 模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

　　9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框(卖礼品的MM也很漂亮哦)，再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗?

　　　　装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个 对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

        10、FA?ADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Fa?ade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。

　　　　门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用 。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

　　11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。

　　　　享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

　　12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀?”“你多大了?”“身高多少呀?”这些话，真烦人，写个程序 做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

　　　　代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

以下是引用片段：
　　　　public interface FactoryProxy{
　　　　　　public People createBoy();
　　　　　　 public People creteGirl();
　　　　}

　　13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上 “Hi,可以做我的女朋友吗?如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!

　　　　责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接

　　　　起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

　　14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送 COMMAND，就数你最小气，才请我吃面。”，

　　　　命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

        15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只 要做一个Interpreter，照着上面的脚本执行就可以了。

　　　　解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

　　16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。

　　　　Mary：“想要我跟你结婚，得答应我的条件”

　　　　我：“什么条件我都答应，你说吧”

　　　　Mary：“我看上了那个一克拉的钻石”

　　　　我：“我买，我买，还有吗?”

　　　　Mary：“我看上了湖边的那栋别墅”

　　　　我：“我买，我买，还有吗?”

　　　　Mary：“我看上那辆法拉利跑车”

　　　　我脑袋嗡的一声，坐在椅子上，一咬牙：“我买，我买，还有吗?”

　　　　……

　　　　迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色 变化。

　　17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这 里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。

　　　　调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

　　18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与 哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。

　　　　备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一 个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

　　19、OBSERVER—想知道咱们公司最新MM情报吗?加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知 我们，直接发布给邮件组，我们作为订阅者(观察者)就可以及时收到情报啦

　　观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生 变化时，会通知所有观察者对象，使他们能够自动更新自己。

         20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的 MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么?”，已经喜欢上你的MM就会说“几点钟?看完电影再去泡吧怎么样?”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。

　　　　状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子 类。

　　21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目 的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。

　　　　策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

　　22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗?女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现);

　　　　模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

　　23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了; 　

　　　　访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

 

ivy2|Ivy入门学习 - 配置ivy使用artifactory

[转]Ivy入门学习 - Developer - 博客园

[转]Ivy入门学习

[原文] http://www.blogjava.net/aoxj/archive/2009/03/31/263012.html

    欢迎使用ivy参考文档，如果你完全不了解ivy，请在深入阅读这份参考文档之前，简单了解一下它的特性，FAQ和教程。

    参考概要：

    这份文档被分解为以下几个部分

    一. 介绍
          1. 术语 (English / 中文)
        这个部分介绍一些在ivy文档中到处使用的词语，例如组织，模块，配置，设置

          2. 主要概念 (English / 中文 上/下)
        这个部分介绍ivy中使用的主要概念：依赖解析器，变量，表达式，另外还有还对ivy的主要概念---模块配置做了良好介绍。

          3. ivy如何工作
        正如标题显示的，在这里你将得到一些ivy内部是如何工作的说明，这可以帮助你更好的理解和定制使用。   
          4 安装
        这个部分讲述如何安装ivy

    二. Ivy Settings Files
        This part is dedicated to the specification of the settings file of Ivy (usually called ivysettings.xml). It also gives

the list of built-in dependency resolvers available in ivy.

    三. Ivy Files
        This part is the reference of the specification of the module descriptors, the ivy files in which you describe your dependencies. If you have any question of what can be done or not in an ivy file, you will have the answer here.

    四. Ant Tasks
        This part describes how to use ivy from ant. It's in this section that all ant tasks brought by ivy are specified.

    五. Using standalone
      Even though Ivy is most often used from ant, it can also be used from the command line. This page describes how you can do it.

    译者注：在学习ivy的过程中陆陆续续的翻译了一些ivy的参考文档，现在准备将这个工作进行到底，将官方网站上完整的ivy参考文档翻译成中文。上面内容是参考文档的目录，翻译完成的部分我会陆续更新为中文并加入链接。

    英文文档地址请见：http://ant.apache.org/ivy/history/2.1.0-rc1/reference.html

    水平有限，出现错误的地址请多多指正
--------------------------------------------------------
Ivy<1>   
 maven很强大，但是远不完美，令人烦恼的地方也不少。看到Ivy似乎日渐成熟，试试看这个小东西表现如何，毕竟后面有那个强大的我喜欢的ant。

    折腾了一番，整理出来点东西，分享给对ivy同样感兴趣的朋友。依然是"初学"系列，提供给新手入门使用。

一. 下载安装

    从官网http://ant.apache.org/ivy/下载到最新的ivy2.0.0正式版，选择的是with dependencies的包。

    在安装ivy之前，请先安装好ant1.6以上版本，因为Ivy是基于ant的。

    参照官网的安装，将下载下来的ivy安装包解压，然后复制ivy的jar文件到ant的lib目录下(ANT_HOME/lib)。设置系统属性IVY_HOME到ivy的安装目录，比如G:\soft\ivy\ivy200。

    另外一个简单的安装方法，就是直接到ivy的src/example/hello-ivy 目录下执行ant，会从网上下载ivy并安装的。

二. 设置工作目录

    Ivy 使用"ivy.default.ivy.user.dir"作为工作目录，ivy通过以下方式确认该目录的具体路径：

    1. 查找变量ivy.default.ivy.user.dir
    2. 如果没有找到，查找变量ivy.home
    3. 如果还没有找到，查找变量user.home，然后使用user.home/.ivy目录

    默认安装而没有专门设置前，前两个变量不存在，因此ivy就会使用user.home作为默认工作目录.

    Ivy 使用cache目录来存放缓存文件，ivy通过以下方式确认该目录的具体路径：
    1. 查找变量ivy.cache.dir
    2. 如果没有找到，使用ivy.default.ivy.user.dir/cache

    默认安装而没有专门设置前，前ivy.cache.dir变量不存在，因此ivy就会使用 ivy.default.ivy.user.dir/cache，由于ivy.default.ivy.user.dir在该情况下默认使用 user.home，因此最后的结果就是使用user.home/cache目录.

    修改默认工作路径的方法，很明显，设置上述的几个变量值即可。比如需要将ivy.default.ivy.user.dir设置到一个特定的目录而不是使用当前操作系统的user.home路径，对于ivy，可以通过设置ant属性的方式。比如修改build.xml文件，增加以下内容
    <property name="ivy.default.ivy.user.dir" value="G:\soft\ivy\userdir" />
    这样就将工作路径修改过去，cache目录也随之改变，避免重新安装操作系统/安装多操作系统等情况下对当前操作系统和用户的依赖。

    由于build.xml文件通常都是项目文件，需要提交到cvs、subversion等版本控制系统中，因此直接在里面写路径不大适合，一旦修改需要改动所有项目的build.xml，而且不同开发人员要求路径相同，不大合理。考虑到ant是可以方便读取系统环境变量的，因此可以用环境变量来定义具体的路径，ant简单使用该环境变量：
    设置环境变量env.ivy.default.ivy.user.dir=G:\soft\ivy\userdir
    build.xml中这样引用：
    <property environment="env"/>
    <property name="ivy.default.ivy.user.dir" value="${env.ivy.default.ivy.user.dir}" />

    以上目录使用规则可以直接看ivy的源代码，很清晰，类org.apache.ivy.core.settings.IvySettings中 IvySettings()的构造函数很容易看出上面的规则。（惭愧，刚学ivy，对配置不熟悉，又找不到相关的配置说明文档，只好蛮干了)


三. 配置文件路径
    ivy使用变量名ivy.settings.file来设置配置文件路径，由于没有找到相关的设置文档，因此干脆打开源文件看代码。
    在类org.apache.ivy.ant.IvyAntSettings中，函数defineDefaultSettingFile()中有相关的代码：

    1. 查找变量名ivy.settings.file
    settingsFileName = variableContainer.getVariable("ivy.settings.file");

    2. 可能的路径，依次是项目BaseDir(应该是ant的build.xml文件中定义的BaseDir，通常是项目根路径)，当前路径，很奇怪居然不查找诸如ivy.default.ivy.user.dir的路径，甚至连ivy.settings.dir都不去查找，莫名其妙
    File[] settingsLocations = new File[] {
                new File(getProject().getBaseDir(), settingsFileName),
                new File(getProject().getBaseDir(), "ivyconf.xml"),
                new File(settingsFileName),
                new File("ivyconf.xml")
        };

    3. 上面四个路径依次查找
        for (int i = 0; i < settingsLocations.length; i++) {
            file = settingsLocations[i];
            verbose("searching settings file: trying " + file);
            if (file.exists()) {
                break;
            }
        }

    4. 如果没有找到，则取默认设置
    if (!file.exists()) {
                info("no settings file found, using default...");
                file = null;
                url = IvySettings.getDefaultSettingsURL();
        }
    默认配置文件是ivy.jar包中的org.apache.ivy.core.settings.ivysettings.xml，如果不做任何相关配置，一般都使用这个默认配置。

    了解ivy是怎么工作了，想配置就方便了。比如如果希望为当前项目单独设置，则可以:
    1. 在当前项目BaseDir目录下放置ivyconf.xml文件
        new File(getProject().getBaseDir(), "ivyconf.xml")
        这个是最简单的方案了，奇怪的是这里的文件名是ivyconf.xml，很郁闷，我用ivysettings.xml测试了好久都不生效，原来根结在这个地方。风格不统一，估计是新老版本兼容问题，幸亏可以看到源代码。

    2. 或者同时设置ivy.settings.file为要求的文件名，将该文件放置在项目BaseDir目录下
        new File(getProject().getBaseDir(), settingsFileName)
        比如设置ivy.settings.file=ivysettings.xml，这样可以和jar包中的文件名保持一致。似乎用处不大？

    3. 为了让所有项目统一使用相同配置，可以考虑直接将ivy.settings.file指向一个公共的配置文件
        比如设置ivy.settings.file为${env.ivy.default.ivy.user.dir}/ivysettings.xml
        这样就不必每次都重复设置相同的内容，比如ivy的public repository，默认是使用maven2的官网仓库，我们可以修改为使用maven的本地私库，如nexus之类。

    build.xml中的设置：
    <property environment="env"/>
    <property name="ivy.default.ivy.user.dir" value="${env.ivy.default.ivy.user.dir}" />
    <property name="ivy.settings.file" value="${ivy.default.ivy.user.dir}/ivysettings.xml" />


四. 和nexus集成

    我喜欢使用nexus来搭建maven2的私服，即使家里机器上的私服只有我一个人用......
    因此想让ivy能连到我现有nexus私服，google了一下找到解决的方法，实验成功，只需要修改两个地方：

    1. ivysettings.xml
        将原有的
    <include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
        修改为
    <include url="./ivysettings-public.xml"/>

    2. 在ivysettings.xml相同目录下放置ivysettings-public.xml文件
        实际从ivy.jar包中copy出对应文件，然后修改
        <ibiblio name="public" m2compatible="true" root="http://192.168.0.30:8081/nexus/content/groups/public/"/>
        注意这里的name="public"不能改，否则会报错。

        有关public, shared, private三个repository的资料，请参考官方文档，说明的很细致
        http://ant.apache.org/ivy/history/latest-release/tutorial/defaultconf.html

added in 2009-04-22:
        上面的内容有点乱，三个星期后我在另一台机器上安装ivy时，对照本文看居然都没有直接搞定，又浪费了点时间折腾......
        决定再�嗦一点，下面是具体操作步骤，这次足够简单直接了：
1) install ant1.6+
    set env ANT_HOME=G:\soft\ant
    set Path, add ANT_HOME/bin

2) install ivy
    set env IVY_HOME=G:\soft\ivy\ivy200
    set env ivy.default.ivy.user.dir=G:\soft\ivy\userdir

3) config ivy for all projects and users
    1. copy ivysettings.xml to userdir
    2. copy ivysettings-public.xml to userdir
    3. open ivysettings-public.xml, edit m2 URL

4) add ivy setting to ant build.xml of project
    ......
    <property environment="env"/>
    <property name="ivy.default.ivy.user.dir" value="${env.ivy.default.ivy.user.dir}" />
    <property name="ivy.settings.file" value="${ivy.default.ivy.user.dir}/ivysettings.xml" />
    ......

added in 2009-05-29:
    在linux上测试的时候，才发现一个问题，ivy.default.ivy.user.dir是不能作为linux下的环境变量名的！为了保持一致，只好修改为IvyDefaultUserDir。
    即：
    set env IvyDefaultUserDir=G:\soft\ivy\userdir
    ......
    <property environment="env"/>
    <property name="ivy.default.ivy.user.dir" value="${env.IvyDefaultUserDir}" />
    <property name="ivy.settings.file" value="${ivy.default.ivy.user.dir}/ivysettings.xml" />

--------------------------------------------------------
Ivy<2>

在ivy中使用了很多术语，他们的定义如下：

    * Organisation / 组织
    * Module / 模块
    * Module Descriptor / 模块描述符
    * Artifact / 制品
    * Type of an artifact / 制品类型
    * Artifact file name extension / 制品文件扩展名
    * Module Revision / 模块修订本
    * Branch / 分支
    * Status of a revision / 修订本状态
    * Configurations of a module / 模块配置
    * Ivy Settings / ivy设置
    * Repository / 仓库

一. 概述

    下面的插图展示了所有的关键术语：

    http://ant.apache.org/ivy/history/2.1.0-rc1/images/ivy-terminology.png

二. Organisation / 组织

    组织可以是公司，个人，或者仅仅是任何开发软件的一组人。原则上，ivy仅处理单一级别的组织，这意味着他们在ivy模块描述符中拥有一个扁平的命名空间。因此，如果使用分层的命名习惯，用ivy的描述符只能描述树形组织结构。组织名用来将同一个团队生产的软件保持一致，仅仅是帮助定位他们发布的。
作品。

    在ivy中通常使用反转的域名作为组织名，因为域名是独一无二的。域名为www.example.com的公司可以使用com.example，或者如果他们有多个团队，他们的组织名可以以com.example开头(例如com.example.rd, com.example.infra, com.example.services)。组织名并不强制要求一定要是域名反转，或者全局唯一，但是唯一的名字是高度推荐的。被广泛认可的商标或者商业名的拥有者可以选择使用他们商标名。如org.apache, ibm, jayasoft

    注意ivy的“组织”非常类似maven POM 中的"groupId"。

三. Module / 模块

    模块是一个完备的可重用的软件单元，带有一个修订版控制方案。

     ivy仅关心模块的发布比如大家熟知的"artifacts"，还有用于表示他们的模块描述符。这些发布，包括模块的每一个修订版本，在仓库中管理。换句话说，对于ivy，一个模块就像一个修订版本链，每个修订版本由一个描述符和一个或多个artifact构成。例如：hibernate- entitymanager, ant

模块描述符
    模块描述符是识别模块的一般方法：识别符(组织，模块名，分支和修订版本)，已发布的制品，可能的配置和依赖。

    在ivy中最通用的模块描述符是Ivy Files，带有ivy特定语法的xml文件，通常被称为ivy.xml。

    但是既然ivy同样兼容maven2的原数据格式(名为pom, Project Object Model, 项目对象模型), pom文件也可以作为模块描述符使用。

    而且由于ivy支持可插入式的模块描述符解析器，因此几乎可以使用任何东西作为模块描述符。

四. Artifact / 制品

    制品是一个为模块修订版本的发布而准备的单独文件，作为开发的一个产品。

    通常推荐使用压缩包格式，因为容易管理，传送和存储。同样的理由，通常一个模块只有一个或者很少的制品。无论如何，制品可以是任意文件类型，在一个单独的模块中可以申明任意数量。

    在java的世界种，通常的制品是Java archives 或者说jar文件。在很多情况下，模块的每个修订版本只发布一个制品(例如 jakarta-log4j-1.2.6.tar.gz), 但是他们中的一些发布多个制品，取决于模块的使用。(像 apache-ant 二进制和源文件，分别打包为zip, gz 和bz2 格式).例如: ant-1.7.0-bin.zip, apache-ant-1.7.0-src.tar.gz

制品类型

    制品类型是一个特别类型的制品范例的范畴（翻译的很晕，原文：The artifact type is a category of a particular kind of artifact specimen.）。这是基于制品的已制定计划或者制品如何提供的分类法，而不是包的格式类型或者制品如何发布。

    虽然制品的类型可能暗示它的文件格式，但是他们是两个不同的概念。制品的文件扩展名和它的格式联系更紧密。例如，Java archives的情况，制品类型"jar"显示它确实是一个Java archive文件，符合JAR文件规范。它的文件扩展名只是凑巧也是"jar"。另一方面，对于源文件发布包，制品类型可能是"source"，虽然文件扩展名可以是"tar.gz", "zip", "java", "c", 或 "xml"。所以，制品类型基本上是用来解释它的目的的抽象功能类别，而制品文件扩展名是更加具体的技术上的文件格式和名称的标记。

    定义模块的适当的制品类型由开发组织决定。通常的选择包括: "jar", "binary", "bin", "rc", "exe", "dll", "source", "src", "config", "conf", "cfg", "doc", "api", "spec", "manual", "man", "data", "var", "resource", "res", "sql", "schema", "deploy", "install", "setup", "distrib", "distro", "distr", "dist", "bundle", 等等.

    模块描述符不是真正的制品，但是他们可以作为一个制品类型，比如"descriptor"(ivy file 或者 Maven POM).

    电子签名或者摘要本身不是真正的制品，但是他们可以再仓库中被找到。他们也被作为一种制品类型，例如"digest" (md5 or sha1)。

五. 模块修订本和状态

模块修订本

    模块的每一个被发布的唯一状态都被分配一个唯一的修订本编号或者版本名。ivy可以帮助为模块的发布生成修订本编号，并将修订本发行到仓库中，但是修订本控制的其他方便，尤其是源文件修订，必须由单独的版本控制系统管理。

    因此，对于ivy，修订本经常对应模块的一个发布版本。它可以是public, shared 或 local delivery，一个发布，一个里程碑或者一个集成构造，一个alpha或者bata版本，一个nightly build, 或者甚至是一个持续构造。它们都被ivy视为修订本。

    在某些情况下，源文件控制系统的源文件修订本编号可以被用来作为模块的修订本编号，但是这种用法非常少见。它们是两个不同的概念，即使模块的修订本编号是完全或部分从源文件修订本编号中复制过来。

分支

    分支对应于源文件控制管理工具中的分支(有时是stream/流)的标准含义。head, 或者trunk, 或者main stream都被ivy视为分支。

修订本状态

    模块的状态显示模块的修订本的稳定程度。它被用来统一所有模块依赖的状态，防止在模块的release中使用依赖的集成修订本。

    ivy默认定义三种状态

    * integration/集成: continuous build，nightly build等产生的修订本归于此类
    * milestone/里程碑: 发布给公众但是还没有真正完成的修订本归于此类
    * release/发行: 完整测试并被打好标签的修订本归于此类

    在1.4版本之后，这个列表可以在settings file/设置文件中配置。

六. 模块配置

    模块配置是使用或者构建一个模块的方法。如果同一个模块有不同的依赖，基于如何使用，在ivy中这些不同的依赖组合被称为它的配置。

    一些模块可能以不同的方式被使用(考虑hibernate，可以在应用服务器内部或者外部使用)，而这种方式可能改变你需要的制品(这种情况下的 hibernate, jta.jar仅仅当它被在应用服务器外部使用时才需要)。此外，模块可能仅仅在build时需要一些其他模块或者制品，而在运行时需要其他一些。所有这些不同的使用或者构建模块方式在ivy中被称为模块配置。


    更多配置和他们在ivy中如何被使用的细节，请参考主要概念的页面。

七. ivy设置

  ivy设置文件是xml文件，用于配置ivy来指示从哪里可以找到模块和如何找到模块。

设置的历史

    在ivy2.0之前，设置文件被称为配置文件，通常名为为ivyconf.xml。这导致了模块配置和ivy配置文件之间的混淆，因此被重命名为配置文件。如果你偶尔发现ivyconf文件，或者某些被称为配置文件的东西，大多数情况下都只是因为它是没有更新的信息(文档，指南和文章). 可以随便报告任何类似这样的问题，如果你在这封文档中发现这样的不一致。

八. 仓库

    在ivy中，被称为仓库的是ivy用来发现你要求的模块的制品和描述符的分布站点位置(也就是大多数情况下的ivy文件)。ivy可以使用非常精巧的配置的复杂仓库。你可以使用Dependency Resolvers来做这些。

--------------------------------------------------------
Ivy<3>

    英文原文：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html

    因内容太长而拆分，下面是第一部分：

一. 依赖解析器

    依赖解析器是ivy中使用的可插入是的类：
    * 发现ivy文件中的依赖
    * 下载依赖的制品

    制品下载的概念很大：制品可以在网站上，或者在你机器上的本地文件系统上。下载是从仓库取文件放到ivy缓存的行为。
    而且，解析器的职责是找到ivy文件并下载制品，这有助于实现不同的解析策略。
    如你所见，依赖解析器可以被认为是负责描述仓库的类。
    如果你想知道在ivy中有哪些解析器可用，你可以转到对应的配置章节。

二. 模块配置说明

    模块配置在术语页面已经被描述，是用来使用或者构建模块的方法。配置是ivy的重要部分，需要更多的说明。
    当你定义一种方式来使用或者构建模块时，你可以在这个配置中定义哪些制品被这个模块发布，并且你还可以在这个配置中定义哪些依赖是需要的。

    此外，因为ivy中的依赖是以模块而不是制品来表述，因此能够在你定义的模块中定义依赖的配置是必须的就显得很重要了。这就是配置映射。

    如果你仅仅使用单一的模块并且不想操心配置，你可以不理会他们。它们依然存在，导致ivy无法在没有配置的情况下工作。但是大多数时候，如果你不定义任何东西，ivy会假设你的模块的制品在所有的配置中发行，并且在所有的配置中所有的依赖配置都是必须的。并且在单一模块的情况下工作正常。但是无论何时你想在一个模块内部分隔事物，或者更多的控制发行的东西并通过依赖解析，配置会满足你的大多数要求。

    更多如何定义模块配置，定义制品用哪个配置发布和定义配置映射的细节，请参考ivy文档。配置教程是一个可以教会你学到更多关于这个概念的东西的好地方。

三. 变量

    在配置的过程中，ivy容许定义ivy变量。ivy变量可以被视为类似ant属性，而且使用方式很相似。特别是，在配置文件中使用属性标签来装载包含ivy变量和值的属性文件。
    但是，ant属性和ivy变量之间的最大差别在于ivy变量可以被覆盖，然而ant属性不可以，而且它们在不同的环境下定义。
    实际上当配置完成时，所有ant属性都被导入到ivy变量（如果是从ant中调用ivy）。这意味着如果你在调用配置之后定义一个ant属性，它讲无法作为一个ivy变量来访问。另一方面，ivy变量不能导出到ant，所有如果你在ivy中定义ivy变量，不要试图作为ant属性来使用它们。

    为了使用ivy变量，你必须遵循和ant属性相同的语法：
    ${variablename}
    这个的variablename是变量名

    最后，同样重要的是知道变量代入的时间点。带入是尽可能快的。这意味着当ivy遇到一个变量引用，如果这个变量被定义了，它会试图代入。结果是，这个变量在之后的任何改动都不会影响这个已经代入的值。
    此外，在ant环境中，一串变量将通过ant属性文件装载机制被默认设值（实际上他们被作为ant属性第一次装载，然后被导入为ivy变量，见ant任务），甚至在ant属性自身也将在装载时立即代入，有效地使得仅仅通过ivysettings.properties文件来覆盖某些变量变得没有可能。某些变量因此只能通过ant属性来重载。
    此外，同样非常重要的是理解ivy变量和ivy模式标记(pattern tokens)之间的不同。请翻阅模式的章节来理解什么是模式标记。

四. 模式

    ivy模式在很多依赖解析器和ivy任务中被使用，是构成ivy工作方式的简单方法。
    首先我们给出一个例子。距离说你可以通过提供一个查找制品的模式来配置一个文件系统依赖解析器。这个模式类似这样：
    myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]

    这个模式表明我们使用的仓库是在被称为myrepository的目录中。
    在这个目录中有我们要查找的名为组织和模块的目录。那么每个模块一个目录，名字就是模块名。然后在每个模块目录中我们发现每个制品类型(jars, wars, ivys, ...)有一个目录，在这些目录中我们发现制品被命名为制品id，加一个连字符（横杠），然后是修订本，逗号，制品的扩展名。
    不是很难理解吧？就是这样，现在你能理解模式的概念了！
    多解释一点，模式是由标记组成的，当赋值给特定的制品或模块时标记被替换为实际的值。这些标记和变量不同，因为它们为每个制品做不同的替换，然而变量通常是相同的值。

    你可以在模式中混合使用变量和标记：
    ${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]

    标记是否有用取决于模式在哪里被使用（例如赋值给制品或者模块），但是这里是所有目前可用的标记：

    * [organisation] 组织名
    * [module] 模块名
    * [branch] 分支名
    * [revision] 修订本
    * [artifact] 制品名(或者id)
    * [type] 制品类型
    * [ext] 制品文件扩展名
    * [conf] 配置名
    * [originalname] (since 1.4) 原始的制品名（包括扩展名）

    类型和扩展名的不同在ivy文件文档中已经解释过了。

    从1.2开始， [organization] 可以被 [organisation] 替代使用.
    从1.3开始， 在模式中可以使用可选部分。

    这使得当标志没有定义时可是避免某些输入，而不是仅仅得到一个空的标记。括号被用于界定可选部分，并且在括号中只能有一个标记。因此如果在你在用'(' 和 ')'包围一个标记，如果标记没有值则在括号之间的任何其他文本都将被忽略。

    例如, 假设有这样一个模式: "abc(def[type]ghi)"
    type = "jar" -> 模式展开为: abcdefjarghi
    type = null 或者 "" -> 模式展开为: abc

    更实际的例子：模式[artifact](-[revision]).[ext]
    让你同时接受在修订本被设置时的myartifact-1.0.jar和没有设置修订本时的myartifact.jar(而不是myartifact-.jar)。在你需要保持对制品名的控制时非常有用。

    从1.4开始，附加属性可以在模式中被当成任意其他标记被使用。

五. 最新策略

    ivy经常需要知道两个修订本之间哪个是最新。为了知道这个，ivy使用"最新策略"的概念。当然，有多个方法可以考虑一个修订本是否是最新。你可以选择一个已经存在的或者插入你自己的。
    但是在知道那个修订本是最新的之前，ivy需要有能力去考虑一个模块的多个修订本。因此ivy不得不从目录下得到一个文件列表，为此需要使用依赖解析器。因此在奇怪为什么ivy没有得到你最新的修订本前，请检查你使用的依赖解析器是否和最新的修订本兼容。
    最后，为了得到模块的不同修订本，大多数时候你需要在你的模式中使用[revision]标记，这样无论revision是什么ivy都能得到匹配这个模式所有的文件。只有这样来时使用最新策略来检测那个修订本是最新的。

    ivy有三个内建的最新策略：

    * latest-time
    比较修订本时间来知道哪个是最新的。虽然相对来说这通常是一个好的策略，但是它有一个缺点，和远程仓库进行推断是有代价的。例如如果你使用ivyrep，ivy不得不在知道哪个是最新的之前询问http服务器每个ivy文件的日期。

    * latest-revision
    把修订本进行字符串比较，使用接近于php version_compare 函数的算法。这个算法被用于评估某些文本的特殊含义。例如，这这个策略中，1.0-dev1 被认为在1.0-alpha1之前, 1.0-alpha1在1.0-rc1之前, 1.0-rc1在1.0之前, 1.0在1.0.1之前.

    * latest-lexico
    把修订本进行字符串比较，使用辞典顺序(这个方法被java strong 比较使用)

六. 冲突管理器

    冲突管理器可以在冲突的模块修订本列表中选择需要保留的修订本。
    如果修订本对应相同的模块，举例说相同的组织/模块名对，那么称为冲突的修订本列表。
    可用的冲突管理器列表在可以冲突管理器页面可以得到。
    想得到更多如果配置冲突管理器的细节，请看ivy文件参考的冲突章节。

--------------------------------------------------------
Ivy<4>

 ivy中文参考文档(4)-主要概念(下)
    ivy中引入了一些自己的概念，了解并理会这些概念对ivy的学习使用是有帮助的。这里翻译一下官网的介绍ivy主要概念的文章，原文在此：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html

    因内容太长而拆分，下面是第二部分：


六. 冲突管理器

    冲突管理器可以在冲突的模块修订本列表中选择需要保留的修订本。

    如果修订本对应相同的模块，举例说相同的组织/模块名对，那么称为冲突的修订本列表。

    可用的冲突管理器列表在可以冲突管理器页面可以得到。

    想得到更多如果配置冲突管理器的细节，请看ivy文件参考的冲突章节。

七. Pattern matcher 模式匹配

    从1.3之后在很多地方ivy使用模式来匹配一系列对象。例如，当通过使用匹配所有想排除的模块的模式来声明一个依赖时，你可以立即排除这多个模块。

    ivy使用可插入式的模式匹配器来匹配哪些对象名。默认定义好的有3个：

    * exact
        This matcher matches only string when they are equal to the pattern one
        这个匹配器仅匹配字符串，要求和模式相同。

    * regexp
    这个匹配器容许你使用java1.4或者更高版本的Pattern类支持的正则表达式

    * glob
    这个匹配器容许你使用unix风格的glob匹配器，仅有的能使用的字符是匹配任何字符串的*和精确匹配单个字符的?。注意仅仅当jakarta oro2.0.8在classpath中时这个匹配器才可以使用。

    同样请注意，在任何匹配器中，字符'*'有匹配任意东西的特殊含义。对于不依赖匹配器的默认值尤其有用。


八. 附加属性

    从1.4版本之后在ivy的xml文件中有几个标签是可以通过被称为附加属性的东西来进行扩展。想法很简单：如果你需要更多信息来定义你的模块，你可以添加你需要的属性，然后能够像访问其他属性一样访问它，比如在你的模式中。
    从2.0版本之后，可以并且推荐为你的附加属性使用xml命名空间。使用ivy附加命名空间是最简单的添加你自己的附件属性的方法。

    例如：
    这里是一个ivy文件，属性'color'设置为blue:
    <ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
    <info organisation="apache"
           module="foo"
           e:color="blue"
           status="integration"
           revision="1.59"
    />
    </ivy-module>

    这样当你定义一个基于foo的依赖时你就必须使用附加属性。那些附加属性 被作为标识符实际使用，类似org，name和revision。
    <dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
    你还可以这样定义你的仓库模式:
    ${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
    注意在模式中科你必须使用非限定属性名(不带命名空间前缀)

    如果你不想使用xml命名空间，这是可以做到的，但是你需要使ivy文件验证失效，因为你的文件不再符合任何正式的ivy xsd。查看设置文档来得知如何使验证失效。


九. 校验和
    从1.4版本后，ivy容许使用校验和，被称为digester，来验证下载文件的正确性。
    目前ivy支持MD5和sha1算法。

    使用MD5还是sha1的配置可以是全局的，或者是由依赖解析器设置。全局是使用变量ivy.checksums来列举要进行的检测(仅支持md5和sha1)，在每个解析器上你可以使用属性

checksums来覆盖全局设置。

    设置是逗号分隔的使用的校验和算法。
    在检测过程中(下载的时候)，找到的第一个校验和将被检测，然后就结束。这意外着如果你设置为"sha1, md5"，那么如果ivy发现了一个sha1文件，它将使用这个sha1来比较下载文件的sha1，并且如果比较是通过的，ivy将认为这个文件是正确的。如果没有发现sha1文件，ivy将查找md5文件。如果没有发现任何一个，将不进行检测。
    在发布过程中，任何例举出来的校验和算法都将被计算和上传。

    默认的校验和算法是"sha1, md5"。
    如果你想修改这个默认值，你可以设置变量ivy.checksums。因此想使校验和验证失效，你仅仅需要设置ivy.checksums为""。


十. 事件和触发器

    从1.4版本之后，当ivy完成依赖的解析和一些其他任务，ivy将在最重要的步骤前后发出事件。你可以使用ivy的api来监听这些事件，或者你甚至可以注册一个触发器在特定事件发生时来执行特定的动作。

    这是尤其强大而灵活的特性，例如它容许在依赖解析前执行依赖的构建，或者在依赖解析过程中精确地追踪发生的事情。

    更多关于时间和触发器的细节，请看本文档的配置章节中的触发器文档页面。

十一. 循环依赖

    从1.4版本之后，循环依赖可以是直接或者间接。例如，如果A依赖A，这是循环依赖，如果A依赖B而B依赖A，这也是循环依赖。

    在ivy1.4之前循环依赖会导致viy产生错误。到ivy1.4止，当ivy发现循环依赖时的行为可以通过循环依赖策略来配置。

    3个内建的策略可用：

    * ignore/忽略
        循环依赖仅仅用详细的信息警告进行标志。
    * warn / 警告
        和忽略相同，除非它们被标识为警告(默认)
    * error / 错误
        发现循环依赖时终止依赖解析

    查看配置页面来看如果配置你想使用的循环依赖策略。

十二. 缓存和变更管理

    ivy非常依赖本地缓存来避免过于频繁的访问远程仓库，从而节约网络带宽和时间。

1) 缓存类型

    ivy缓存由两个不同部分组成:

    * 仓库缓存
        仓库缓存是ivy保存从模块仓库下载的数据的地方，和一些关系到这些制品的元信息在一起，和他们的原始位置一样。

    * 解析缓存
    这个部分的缓存用来保存被ivy用来重用解析过程的结果的解析数据。
    这个部分的缓存每次完成一次新的解析时都被覆盖，并且决不能被多进程同时使用。

    通常只有一个解析缓存，但是你可以定义多个仓库缓存，每个解析器可以使用单独的缓存。

2) 变更管理

    为了加快依赖解析和缓存使用的方法，ivy默认认为修订本从不修改。因此一旦ivy在它的缓存中有这个模块(元数据或者制品)，ivy信任缓存，甚至不再查询仓库。大多数情况下这个优化时非常有用的，并且只要你遵循这个规范就不会引起问题: 修订本从不变更。除性能之外，还有几个好的原因来遵循这个原则。

    无论如何，取决于你当前的构建系统和你的依赖管理策略，你可能更愿意更新你的模块。有两种变更需要考虑:


    2.1) 模块元数据变更

    模块提供者不考虑经常优化模块元数据，他们更多的关注他们的api或者行为(如果他们甚至提供模块元数据)。我们不喜欢的事情经常发生：我们不得不更新模块元数据，一个依赖被遗忘了，或者另一个丢失了......

    在这种情况下，在你的依赖解析器上设置checkModified为"true"将是一个解决方案。这个标记告诉ivy需要检查模块的元数据相比较缓存是否被修改. ivy首先检查仓库中元数据的最后修改时间以决定只在必要时下载它，同样只在需要时更新它。


    2.2) 制品变更

    一些用户，尤其是从maven2过来的用户，喜欢使用一个特别的修订版本来处理经常变更的模块。在maven2中这个通常被称为SNAPSHOT(快照) 版本，并且有一种主张认为这样可以帮助节约空间，因为只需要为开发时可能创建的大量的中间产物保留一个修订版本。

    ivy使用"changing revision"的概念来支持这种方法。changing revision就是这样：一个ivy认为随着时间推移始终可能变更的修订版本.为了处理这个，可以通过使用以来标签明确指定一个依赖为可以变更，或者在解析器上使用changingPattern 和changingMatcher 属性来知名那个修订版本或者修订版本组可以被认为是变更的。

    一旦ivy知道一个修订版本是变更的，它将遵循这样的原则来避免过于频繁的检查仓库：如果模块的元数据没有修改，它将认为整个模块(包括制品)没有修改。即使如果模块描述符文件已经修改，它将检查模块的发行数据来看这个是不是同一个修订版本的一个新的发行。然后如果发行数据被修改了，它将检查制品的最后修改时间戳，并相应的下载它们。

    因此如果你想使用变更修订版本，使用发布任务来发布你的模块，请小心更新发布数据，然后一切都会工作的很好。并且记住也要将你的解析器设置checkModified=true"。


十三. 路径处理

    作为一个依赖管理器，ivy有一系列的文件相关操作，大部分使用路径或者路径模式来在文件系统上定位文件。

    这些路径可以明确是的相对路径或者绝对路径。我们推荐经常使用绝对路径，这样你不必担心你的相对路径的基准路径是什么。ivy提供一些变量，可以被用来作为你的绝对路径的基准路径。例如，ivy有基准路径的概念，这个基本和ant一致。你可以使用变量ivy.basedir来访问这个基准目录。因此如果你有类似这样的路径：

${ivy.basedir}/ivy.xml

    你就得到了一个绝对路径。在设置文件中，你同样有一个名为ivy.settings.dir的变量指向你的设置文件所在的目录，这使得定义和这个目录相关的路径变得非常容易。

    如果你真的想使用相对路径，被用于实际定位文件的基准路径取决于相对路径在哪里被定义：

    * 在ivy文件中，路径是相对于ivy文件自身(在ivy文件中唯一可能的路径是用于配置包含申明)。
    * 在设置文件中，用于文件包含的路径(也就是属性文件装载和设置文件包含)是相对于设置文件所在的目录。所有其他路径除非明确记录否则必须是绝对路径。
    * 在ivy的ant任务和ivy参数或选项中，路径是相对于ivy基准路径的，当在ant中调用时这个路径就是ant的basedir路径一致。
    

风流终被雨打风吹去……

Ivy|Working with Ivy - Artifactory

Working with Ivy - Artifactory - Confluence

Setting up Ivy to work with Artifactory In order to make Ivy work with Artifactory, the following files must be present and configured: The Ivy settings - ivysettings.xml - used to configure artifact resolution and deployment using repositories in Artifactory. The Ivy modules - ivy.xml - where the project's modules and dependencies are declared. The Ant build - build.xml - which is used to execute the ANT tasks that will, in turn, use Ivy for artifact resolution and deployment. Ivy Settings - ivysettings.xml The ivysettings.xml file holds a chain of Ivy resolvers, which are used for both resolution and publishing (deployment). Resolvers exist for both regular artifacts and Ivy module files. There are a couple of options to set up Ivy to work with Artifactory by configuring resolvers in ivysettings.xml: The ibiblio resolver and the URL resolver. The iBiblio Resolver This resolver is used strictly for dependency resolution. By default it assumes artifacts in your repository are laid-out in the popular standard Maven 2 format (which may not always be the case). The ibiblio resolver can resolve artifacts from remote Maven 2 HTTP repositories, and if you use version ranges it relies on maven-metadata.xml files in the remote repository to gather information on the available versions. To use the ibiblio resolver add the following to your ivysettings.xml: <ibiblio name="artifactory" m2compatible="true" root="http://localhost:8080/artifactory/libs-releases"/> The root URL needs to point at an Artifactory repository. In this case, the pre-configured 'libs-releases' virtual repository. The m2compatible property pre-configures the resolver with an artifact pattern that follows the Maven 2 standard layout. The URL Resolver The URL resolver can be used for dependency resolution and/or deployment of both regular artifacts and Ivy module files. To publish or resolve artifacts to/from Artifactory configure a URL resolver with the pattern that matches your target repository layout for both Ivy and artifact files, e.g.: <url name="artifactory-publish"> <!-- You can use m2compatible="true" instead of specifying your own pattern --> <artifact pattern= "http://localhost:8080/artifactory/libs-snapshots-local/\]\[organization\]/\[module\]/\[revision\]/\[artifact\]-\[revision\].\[ext\]"/> <ivy pattern="http://localhost:8080/[organization]/[module]/[revision]/ivy-[revision].xml" /> </url> The URL resolver uses HTML href analysis to learn about the available versions of a remote artifact. This is a less reliable method compared to the ibiblio resolver way, though it works fine with remote Artifactory servers. Using a Chain Resolver You can mix resolvers under a chain resolver in Ivy which will use sub-resolvers for dependency resolution and publishing. Please refer to the relevant Ivy documentation. Ivy Modules - ivy.xml ivy.xml files contain a list of dependency declarations that are needed to be resolved for the build. You can use the Artifactory UI to obtain dependency declaration snippets by selecting either an Ivy module or a POM artifact and copying the "Ivy Dependency Declaration" section into your ivy.xml file. Ant Build - build.xml To work with Ivy for dependency resolution you need to use <ivy:configure/> in your build.xml file. This will load the ivysettings.xml. The resolution of artifacts is done using <ivy:retrieve/>. Please consult the Ivy documentation for more detailed information. Publishing to Artifactory In order to publish to Artifactory the <ivy:publish> command needs to be used. Ivy will use the configured resolver to deploy your artifact into Artifactory. For example: <ivy:publish resolver="artifactory-publish" overwrite="true"> <!-- Use overwrite="true" if you wish to overwrite existing artifacts and publishivy="false" if you only want to publish artifacts not module descriptors --> <artifacts/> </ivy:publish> Please consult the Ivy documentation for more detailed information. Searching the Content of Ivy Modules You can search the content of Ivy modules in Artifactory. From Artifacts:POM/XML Search select the name you use for Ivy modules (typically ivy.xml) and use an XPath query to define your search. For example: Support for other Ivy file patterns Though ivy.xml is the common name for Ivy modules, Ivy does not mandate a standard name. Out of the box *.ivy is also supported, and you can instruct Artifactory to index other file patterns by editing the artifactory.xmlAdditionalMimeTypeExtensions property in $ARTIFACTORY_HOME/artifactory.system.properties. Of course this applies to XML files in general.

Labels parameters