講個笑話吧，關(guān)于"keep it simple"
這其實是個真實的故事，發(fā)生在兩年前，當(dāng)我從上一家公司離職時。
當(dāng)時我移交了一個重要模塊，后來不久，記不清了，大概一兩個月后吧，有關(guān)系不錯的同事告訴我說：某某人大肆宣揚，***模塊我只找個了***的人，*天就接手了，云云。
言下之意自不必說。
而我，則將上述評論視為對自己的嘉獎，深以為榮。
*******************************************************************************
為了大家能看懂這個笑話，羅嗦一點介紹兩個背景故事：
1. 最驕傲的事
工作9年了，回首看最令自己驕傲的事情，就是在07年的夏天，加班加點的工作了1個半月，將上述模塊的新需求完成。開發(fā)模式是我最喜愛的TDD + 持續(xù)重構(gòu)，完備的unit測試案例覆蓋。后面測試中，3位負(fù)責(zé)測試同事用了三天的時間，測試完成所有的測試案例，全部一次性通過，沒有一個bug，哪怕是小bug。
此記錄本人之后兩年中一直試圖復(fù)制，至今沒有成功。
2. 荒謬的問題
發(fā)生在離職做上述模塊移交時，被接收人問了一個問題：項目代碼里面，test目錄下是什么東西?。?/div>
import junit.***, extends TestCase...
無言以對。
摘要: Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)為Tokyo Tyrant的基礎(chǔ)教程。
閱讀全文
摘要:
Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)介紹Tokyo Tyrant的遠(yuǎn)程數(shù)據(jù)庫API，Lua擴展和協(xié)議。部分細(xì)節(jié)內(nèi)容沒有翻譯。
閱讀全文
摘要:
Tokyo Tyrant基本規(guī)范，翻譯自Tokyo Tyrant官網(wǎng)。
本節(jié)介紹Tokyo Tyrant的客戶端程序。
閱讀全文
摘要: Tokyo Tyrant基本規(guī)范，翻譯自tt官網(wǎng)，地址為http://fallabs.com/tokyotyrant/spex.html。
本節(jié)介紹Tokyo Tyrant的服務(wù)器程序。
閱讀全文
摘要: Tokyo Tyrant基本規(guī)范，翻譯自tt官網(wǎng)，地址為http://fallabs.com/tokyotyrant/spex.html。
本節(jié)介紹Tokyo Tyrant的基本知識和安裝方法。
閱讀全文
摘要: Solr是一個基于Lucene java庫的企業(yè)級搜索服務(wù)器，本文記錄了solr的安裝過程，版本為最新的1.4.1。
閱讀全文
摘要: Tokyo Tyrant是目前評價最高的key-value數(shù)據(jù)庫之一，本文記錄在linux(suse11)上的安裝過程。
閱讀全文
摘要: 一直在使用easymock作為mock工具，但是easymock有一個一直令我極其惱火的地方：easymock將interface和class的mock區(qū)分開，給出了針對interface mock的easyMock和針對class mock的easyMock class extension。兩種mock被嚴(yán)格區(qū)分開，連jar包都是兩個，使用時不能混用，比如不能用easymock (非class extension)來mock class。
easymock已經(jīng)發(fā)布了新的3.0版本，該版本的主要改進就是消除上述的問題，新版本中可以直接mock class，不再強制使用easyMock class extension。
強烈推薦還在使用2.*的朋友們升級到3.0版本。
閱讀全文
摘要: 有遇到類似的TortoiseSVN / subversive 信息無法識別的問題的朋友，可以這個方法。
閱讀全文
摘要: sonar 安裝配置筆記, 基于SUSE SLSE11, mysql.
閱讀全文
摘要: 近期自己折騰自己，放著正統(tǒng)的maven + junit不用，卻準(zhǔn)備用ant + ivy 替代maven做依賴管理，用testng替代junit做單元測試。
閱讀全文
摘要: 眾所周知，對于高動態(tài)高可擴展的應(yīng)用，OSGI是一個非常好的平臺。但是，也因此增加了復(fù)雜性，開發(fā)中對service的依賴變得復(fù)雜。這也是 service的關(guān)系管理成為OSGI中一個非常重要的部分，我們來看看OSGI中service依賴關(guān)系管理的方式。篇幅原因，只關(guān)注發(fā)展歷程，不具體介紹每個方式的詳細(xì)實現(xiàn)細(xì)節(jié)。
概括的說，目前在OSGI中主要有以下幾種service依賴關(guān)系管理的方法：
1. Service listener
2. Service binder
3. Dependency Manager
4. Declarative Services
5. iPOJO
6. blueprint
閱讀全文
摘要: 當(dāng)時實際上，我們在檢查ThreadDeath的調(diào)用信息時，說明這個出現(xiàn)init()錯誤的filter還是被glassfish正常調(diào)用去執(zhí)行doFilter()方法，這里和j2ee API的要求是不符合的。有點奇怪的是，glassfish一向是以嚴(yán)格遵循j2ee規(guī)范而著稱，居然在這里一反常態(tài)。
而更令人 郁悶的是，glassfish在處理這個有filter初始化出現(xiàn)ServletException異常的webapp時的前后表現(xiàn)：首先這個 webapp的啟動沒有問題，狀態(tài)正常。filter也被認(rèn)為可以正常工作并加入了filter鏈。webapp中的功能正常，可以正常的接收請求并轉(zhuǎn)發(fā)給內(nèi)容業(yè)務(wù)處理模塊。從這些跡象看這個webapp基本沒有問題。但是后面glassfish卻莫名其妙的認(rèn)定，“this web application instance has been stopped already”，從而以ThreadDeath這種非常規(guī)的error來報錯。
閱讀全文
摘要: 對比最近遇到的兩個事情，明顯感覺sun有力不從心或者心不在焉的感覺，oracle對sun收購的負(fù)面影響至少在開源社區(qū)方面是顯而易見的，個人甚至懷疑oracle正在逐漸放棄之前sun一直努力支撐的開源社區(qū)。
閱讀全文
摘要: 剛剛鄙視完sun，繼續(xù)performance tuning，結(jié)果又發(fā)現(xiàn)問題。
有點懷疑metro是不是根本就沒有做過性能測試，我們的測試場景，openESB下通過bepl調(diào)用4個我們稱為common service的webservice，目前大概做到1200個tps，算下來common service的webservice的tps大概是1200*4 = 5K附近，上面的問題就非常明顯，之前tps沒有上去前沒有這么嚴(yán)重。
可以參考我之前的一個blog， http://www.tkk7.com/aoxj/archive/2010/04/29/319706.html，在解決這里提到的http long connection 和 TIME_AIT的問題之前，我們的tps比較低，cpu壓不上去，當(dāng)時好像這個問題不明顯。后來搞定之后tps上來了才暴露出來。
考慮上一個blog中 == 比較無效導(dǎo)致cache失效的bug，我對metro的代碼質(zhì)量真是很沒有信息。按說這樣的大型項目，release之前怎么也要做做壓力測試，穩(wěn)定性測試之
閱讀全文
摘要: 依然是近期工作中發(fā)現(xiàn)的問題，真實案例，寫下來分享給大家。
總結(jié)：用 == 來比較非enum或者類型安全枚舉的對象實例，這種錯誤一般只有初學(xué)者才犯，萬萬沒有想到，能在metro這樣級別的代碼中也能出現(xiàn)。無限感嘆啊，再次援引同事的評語作為本文的結(jié)束語：
sun的程序員也是程序員??！
閱讀全文
摘要: 近日做性能調(diào)優(yōu)，主要是針對web service，運行于glassfish之上
最終的結(jié)果，還是比較理想的，修改了兩個參數(shù)之后，cpu終于壓上去了，tps也有了巨大的提升，而且TIME_WAIT的連接也大為減少。
但是這兩個max connections參數(shù)的名稱，注釋和實際測試中的效果，都有名不副實的感覺，令人極度困惑。
閱讀全文
摘要: fisheye2.2.1 & Crucible 2.2.1 安裝配置筆記。
閱讀全文
摘要: 今天，嘗試使用slf4j + logback的黃金組合，結(jié)果發(fā)現(xiàn)有點問題，slf4j和logback的最新版本不兼容。當(dāng)然slf4j是1.6.0-RC0，正式發(fā)布時 logback應(yīng)該會跟進發(fā)布新的版本吧。
閱讀全文
摘要: 這是一個真實案例，本周在工作中發(fā)現(xiàn)的，案例情況比較極端，因此顯得很滑稽很搞笑。但是深入一下，還是有些東西值得思考：
下一次，如果我面對一個函數(shù)/接口，要求傳入一個大對象，我手頭只有一個pk，還有一個現(xiàn)成的函數(shù)可以一行代碼就搞定查詢，我要如何才能擋住誘惑？
閱讀全文
摘要:
在SUSE SLES11 下安裝好tomcat6后，考慮方便需要設(shè)置tomcat為開機自動運行。
找到tomcat官方的安裝文檔 http://tomcat.apache.org/tomcat-6.0-doc/setup.html，按照要求安裝，中間發(fā)現(xiàn)有些問題，記錄下來備忘。
閱讀全文
摘要: 這段時間簡單的試用了一下jira，非常滿意。準(zhǔn)備作為個人之后開發(fā)的首選缺陷管理工具，但是當(dāng)時采用的是windows的全集成安裝方式，因此考慮在linux上正式的安裝一下，同時將數(shù)據(jù)庫換成mysql。
雖然最后的結(jié)果不大好，不過上面的這個安裝過程，已經(jīng)遠(yuǎn)比當(dāng)前google上能找到的資料要多了。如果其他朋友有打算用jira4 + resin4 + mysql的，可以稍微參考，少走彎路。如果最后能安裝成功正確使用，希望能告知正確的安裝方法，謝謝！
閱讀全文
摘要: 前面的blog有提到，在選擇CMS系統(tǒng)時試用java版本的magnolia，結(jié)果很失望的放棄了。
重新將目光投向php + mysql的傳統(tǒng)CMS，我選擇了drupal，下面是drupal的安裝配置筆記。
閱讀全文
摘要: SUSE SLES11 上安裝配置mysql的筆記，分享并備忘。
閱讀全文
摘要: 最近想找個cms系統(tǒng)來用用，做點簡單的東西，因為自己比較熟悉java，因此考慮試試java版本的cms系統(tǒng)先，記得之前hibernate網(wǎng)站改版，是換了一個java版本的cms的，特地找過去看了一下，magnolia，google了一下似乎好評還不少。于是下載下來開始研究。
延續(xù)這些年的習(xí)慣，安裝過程一定要詳細(xì)記錄下來，避免日后再次安裝時浪費時間，呵呵。
試用的結(jié)果很不好，還沒有正式開始使用就決定放棄，原因請見下文。
閱讀全文
摘要: 安裝SUSE sles11的過程記錄，分享給有類似需要的朋友，同時備忘。
閱讀全文
摘要: 有兩年多沒有使用resin了，最近打算在機器上安裝一個web container跑點java web app，同時也可能需要支持php，原本打算用apache + tomcat,apache可以加載php模塊來提供php支持，tomcat作為java web container。但突然想到resin，似乎是可以直接支持php的，而且resin的速度也是稍微快于tomcat，于是跑到resin的官網(wǎng)看了一下，恩，新出了4.0版本(慚愧，兩年前用的是3.0或者3.1)。
決定用resin試試，老朋友了。但是在安裝過程中，發(fā)現(xiàn)了一系列問題，尤其是設(shè)置開機自動啟動，記錄下來提供大家參考。
閱讀全文
摘要: 在windows上安裝jira 4.0.2的簡單過程記錄，備忘。
閱讀全文
摘要: 從網(wǎng)上找到的一個設(shè)計模式快速參考，感覺做的非常的好，分享給大家。
閱讀全文
摘要: 在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規(guī)范的要求，一般不容許直接啟動線程。因此在常見的異步/并行任務(wù)執(zhí)行上，會遭遇到比普通javase程序更多的麻煩。
閱讀全文
摘要: 這是近期工作中遇到的一個問題，cxf在glassfish下timeout設(shè)置出現(xiàn)問題，進而引發(fā)的關(guān)于classloader, JAX-WS的一些小故事，很驚訝的發(fā)現(xiàn)cxf在這種情況下根本沒有辦法運行于glassfish平臺。
關(guān)鍵字：glassfish, cxf, classloader, JAX-WS, metro。
閱讀全文
摘要: 如題，osgi 資料收集貼，隨時收集，隨時更新。
閱讀全文
摘要: 在討論這個問題前，先簡單的介紹一下雙重解析器的工作原理：顧名思義，雙重解析是雙重的：它由一個ivyResolver和一個 artifactResolver組成，其中ivyResolver負(fù)責(zé)解析ivy的模塊描述符，而artifactResolver則用于解析制品。換言之，ivyResolver用來指明需要什么，而artifactResolver則負(fù)責(zé)獲取具體的制品文件。
第一次在學(xué)習(xí)ivy的過程中看到ivy中的雙重解析器，就感覺設(shè)計非常的不錯，可以比較好的解決這方面的問題。只要維護好ivyResolver中的依賴，則整個系統(tǒng)中的依賴都被限制在這個范圍中。比如如果有人想用spring2.5.6之外的版本，哼哼，ivyResolver解析器會不工作的......
但是，在實際的使用過程中發(fā)現(xiàn)，雙重解析器的工作模式有點問題：如果目標(biāo)依賴在ivyResolver中可以找到則情況正常，但是如果目標(biāo)依賴在 ivyResolver中沒有定義，ivy居然會在artifactResolver的繼續(xù)查找！然后報告說依賴解析成功已下載云云，而不是我
閱讀全文
摘要: 在maven中，對于一個依賴，除了groupId，artifactId，version這三個屬性來作為標(biāo)志之外，還有一個特殊的屬性可用: classifier。
ivy中依賴對應(yīng)的有屬性org，name,rev，分別對應(yīng)到maven中的groupId,artifactId，version.
但是dependency沒有和maven的classifier屬性相對應(yīng)的屬性，因此無法表示dependency的classifier。這樣就出現(xiàn)問題了，比如上面的testng 的例子，在ivy中如果將對testng的依賴定義寫成上面的樣子，則解析時是無法獲取到我們想到的依賴 testng-5.10.jar的。
那么，在ivy中如何指定classifier屬性呢？
閱讀全文
摘要: 如果你已經(jīng)成功的跟隨并理解了所有的教程，可能你還是需要得到更好的關(guān)于如何在現(xiàn)實世界中只用ivy的描述。
這里有一些有關(guān)系的鏈接.
閱讀全文
摘要: 現(xiàn)在你已經(jīng)看到從一個已經(jīng)存在的倉庫創(chuàng)建你自己的倉庫是如何的簡單，你可能會想知道如何處理更加復(fù)雜的情況，例如當(dāng)源倉庫和目的地倉庫不遵循相同的命名約定。
當(dāng)你有一個已經(jīng)存在的倉庫并且希望從大量的不遵循相同的命名轉(zhuǎn)換的公共倉庫中獲益時，這個問題非常常見?；蛘邇H僅是因為你發(fā)現(xiàn)你作為基礎(chǔ)使用的倉庫不夠一直- 為什么所有的apache commons模塊不適用org.apache.commons 組織？歷史原因。但是如果你安裝你自己的倉庫，你可能不想從歷史中蒙受損失。
幸運的是，對于這種問題ivy有一種非常強大的答復(fù)：namespaces.
閱讀全文
摘要: 在這個步驟中我們使用install任務(wù)來從maven2 倉庫安裝模塊到一個基于文件系統(tǒng)的倉庫。我們首先安裝一個不帶依賴的模塊，然后安裝一個帶有依賴的模塊。
閱讀全文
摘要: install任務(wù)讓你從一個倉庫復(fù)制一個模塊或者模塊集合到另一個倉庫。這對于構(gòu)建和維護一個企業(yè)或者團隊倉庫非常有用。如果你不想你的團隊中的開發(fā)人員都訪問公共的maven2倉庫(例如為了控制哪些模塊可以在你的公司或者你的團隊中使用)，答復(fù)開發(fā)人員的請求來手工增加新的模塊或者新的版本在某些時候變得令人厭煩。
幸運的是install任務(wù)可以在這里提供幫助: 你可以為你的用于維護目標(biāo)企業(yè)倉庫的倉庫維護構(gòu)建使用特定的設(shè)置。這些設(shè)置將指向另一個倉庫(例如maven2 公共倉庫)，因此你只需要使用簡單的命令行要求ivy安裝你需要的模塊。
為了演示這個我們將首先使用個一些基本的ivy設(shè)置文件來展示它是如何工作的，然后我們將使用高級命名空間特性來演示如何在源倉庫和目標(biāo)倉庫之間處理命名不匹配。
閱讀全文
摘要: 這個教程介紹ivy文件中的模塊配置的使用。ivy模塊配置事實上是一個非常重要的概念。某些人甚至告訴我使用ivy而不用ivy配置就像吃乳酪而不動就在你旁邊的Chateau Margaux 1976！
嚴(yán)肅的說，ivy中的配置可以更好的理解為你的模塊的視圖，你將可以看到在這里他們將如何被高效地使用。
閱讀全文
摘要: 在上一個教程中，你已經(jīng)看到如何處理兩個簡單項目之間的依賴。
這個教程將引導(dǎo)你完成在一個更加復(fù)雜的環(huán)境下的ivy使用。這個教程的所有源文件在ivy發(fā)行包的src/example/multi-project下可以得到。
閱讀全文
摘要: 這個示例將舉例說明在兩個項目之間的依賴。
depender項目聲明它使用dependee 項目。我們將闡明兩個事情：
* 被獨立的項目聲明的公共類庫將被依賴的項目自動獲取
* depender項目將獲取dependee項目的"最新"版本
閱讀全文
摘要: 在一些情況下，會發(fā)生這樣的事情:你的模塊描述符(ivy文件，maven pom, ...)被放置在一個地方，而模塊的制品(jars,...)在另外一個地方。
雙重解析器用于滿足這種類型的需求，而這個教程將展示如何使用它。
閱讀全文
摘要: 這個例子演示模塊是如何被多解析器獲得的。使用多解析器在很多情況下是非常有用的，這里是一些例子：
* 來自發(fā)行的單獨的集成構(gòu)建
* 為第三方模塊使用公共倉庫并且為內(nèi)部模塊使用私有倉庫
* 使用一個倉庫來存儲那些在無法管理的公共倉庫里里面的不清晰的模塊
* 使用本地倉庫來暴露在一個開發(fā)人員的位置上生成的構(gòu)建
在ivy中，多解析器的使用是通過一個名為解析器鏈的復(fù)合解析器來支持的。
在我們的例子中，我們將簡單的展示如何使用兩個解析器，一個在本地倉庫而另一個使用maven2倉庫。
閱讀全文
摘要: ivy綁定一些默認(rèn)設(shè)置，這使得在通常環(huán)境下使用ivy很容易。這個教程，接近于參考文檔，解釋這些默認(rèn)設(shè)置是什么和他們怎樣調(diào)整來滿足你的需要。
為了完整的理解設(shè)置的概念和你可以用它們做什么，我們建議閱讀其他和設(shè)置相關(guān)的教程(如Multiple Resolvers 和 Dual Resolver)或者設(shè)置文件的參考文檔。
閱讀全文
摘要: 在這個例子中，我們將看到使用ivy的一個最簡單的方式。不使用任何特殊設(shè)置，ivy將使用maven2 倉庫來解析你在ivy文件中聲明的依賴。讓我們來看一眼涉及到的文件的內(nèi)容。
你將在ivy發(fā)行包的src/example/hello-ivy 目錄下找到這個教程的源文件。
閱讀全文
摘要: 學(xué)習(xí)的最佳方式是實踐！這是ivy教程將幫助你做到的，發(fā)現(xiàn)一些偉大的ivy特性。
這里是非常優(yōu)先的教程，它甚至不需要安裝ivy，如果你已經(jīng)正確安裝了ant和jdk，甚至只需要花費不到30秒的時間
閱讀全文
摘要: 在ivy中有幾個任務(wù)被認(rèn)為是后解析任務(wù)(post resolve task)，并相應(yīng)地共享公用行為和設(shè)置。
這些任務(wù)是：
* retrieve
* cachefileset
* cachepath
* artifactproperty (since 2.0)
* artifactreport (since 2.0)
閱讀全文
摘要: cachefileset,為配置構(gòu)建一個有ivy緩存中的制品組成的ant fileset 從1.2版本起)。
這是一個后解析任務(wù)，有所有后解析任務(wù)共有的所有行為和屬性。注意這個任務(wù)不依賴retrieve，因為構(gòu)建的fileset是由ivy緩存中的制品直接構(gòu)成的。
閱讀全文
摘要: ln命令用于連接文件或目錄,lndir命令用于創(chuàng)建目錄的符號鏈接，和ln不同的是lndir會自動為源文件目錄下所有的文件和子目錄都建立對應(yīng)的符號鏈接.
閱讀全文
摘要: find命令用于查找文件和目錄，任何位于參數(shù)之前的字符串都將被視為欲查找的目錄。
find 可以指定查找條件如名稱，類型，時間，文件大小，權(quán)限和所有者查找，針對多個條件進行與或非的邏輯運算。我們可以控制find的查找的行為，還可以和其他命令組合使用。
閱讀全文
摘要: 為解析過的模塊配置構(gòu)建一個由在ivy 緩存(或者取決于useOrigin 設(shè)置的原始位置)中的制品組成的ant path.
閱讀全文
摘要: ls的用法: ls [OPTION]... [FILE]...
列舉文件信息(默認(rèn)當(dāng)前目錄), 如果-cftuvSUX或者--sort沒有設(shè)置則按照字典順序排序條目。
閱讀全文
摘要: 交付當(dāng)前模塊的解析好的描述符，而且可能執(zhí)行依賴的遞歸交付。
這個任務(wù)主要做兩個事情：
1. 生成一個解析好的ivy 文件
2. 執(zhí)行遞歸交付
閱讀全文
工作中發(fā)現(xiàn)的一個非常奇怪也很有趣事情，有關(guān)MANIFEST.MF文件中的分行和空格的格式要求，分享給大家。
對于通常的MANIFEST.MF文件，一般格式是：
Class-Path: lib/a.jar lib/b.jar lib/c.jar lib/d.jar lib/e.jar lib/f.jar
在一行之內(nèi)將所有的jar包路徑寫上，空格分隔即可。
但是對于一些大型的項目，因為依賴包眾多，比如大于30個，那么如果還寫在一行內(nèi)，就會出現(xiàn)一個長度驚人的行。程序運行倒不會有任何問題，但是對于版本控制就很不友好，如增加或者減少一個依賴包，這行就會被改寫。以后compare不同版本時，只能知道這行被修改了確無法直接知道是做了什么修改，必須通過其他方式才能對比出來。
同樣的問題發(fā)生在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
但是在實際操作時發(fā)生了意料之外的問題，會出現(xiàn)異?；蛘哳悷o法找到，經(jīng)檢查發(fā)現(xiàn)問題出現(xiàn)在MANIFEST.MF的格式上，MANIFEST.MF對于分行和空格是有特殊要求的：
1. 每行的最后一個jar的名稱后不容許有空格
即" lib/b.jar"在b.jar后必須回車結(jié)束本行，不能有空格，一個都不能
2. 每行的開頭必須有不少于2個空格
即" lib/b.jar"在b.jar前必須有不下兩個空格
以上兩個條件有一個不滿足都會出現(xiàn)問題，有點古怪。
摘要: 發(fā)行當(dāng)前模塊的制品和已解析的描述符(已交付的ivy文件)。
這個任務(wù)的目的是發(fā)行當(dāng)前模塊描述符和它的聲明的發(fā)行制品到倉庫中。
閱讀全文
摘要: configure任務(wù)用于通過xml設(shè)置文件來配置ivy。
閱讀全文
摘要: retrieve任務(wù)復(fù)制解析好的依賴到你的文件系統(tǒng)的任何位置。
這是一個post resolve任務(wù)，帶有所有post resolve任務(wù)共有的所有的行為和屬性。
閱讀全文
摘要: 解析任務(wù)實際解析在ivy文件中描述的依賴，并將解析后的依賴放置到ivy緩存中。
如果在resolve任務(wù)前沒有調(diào)用configure任務(wù)，則將使用默認(rèn)的configuration (等同于不帶參數(shù)的調(diào)用configure).
閱讀全文
摘要: buildlist任務(wù)用于獲取按照ivy依賴信息從小到大排序的文件(通常是build.xml文件) 列表，或者相反(從1.2之后)
這個任務(wù)在結(jié)合subant構(gòu)建相關(guān)項目集合時特別有效, 可以確保依賴在其他依賴它的模塊之前被構(gòu)建
閱讀全文
摘要: 轉(zhuǎn)一個blog，關(guān)于如何使用ivy來處理native的依賴，對于有使用JNI開發(fā)的朋友應(yīng)該很有價值。
原文blog地址：http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy/
閱讀全文
我們的團隊一直埋怨說我們的代碼規(guī)模太大，結(jié)構(gòu)太復(fù)雜，維護難度大而成本高。
最明顯的一個弊病，就是在clearcase里面打開一個文件的version tree，密密麻麻，橫七豎八，我們戲稱為"蜘蛛網(wǎng)"。
然而昨天一位出差在外的同事，在維護公司另外一個產(chǎn)品的時候，有了驚喜發(fā)現(xiàn)：
我們的代碼規(guī)模比起來還是差得遠(yuǎn)！
有圖為證：
我的評價只有一個字：
暈!
PS:
解釋一下，有些朋友沒有用過版本控制軟件的version tree，可能不大明白。
這個是version tree，是一個文件(注意，只是一個文件)的版本和分支歷史，一般的版本控制軟件都會提供類似的視圖。
圖上藍(lán)色直線條的是這個文件的不同分支和這個這個分支下的不同版本，紅色的線條是code merge，就是從一個分支的某個版本merge 代碼到另外一個分支上時為了表示這種merge關(guān)系而增加一種表示方式。
從圖上看，這個文件的分支過百了，版本應(yīng)該過千，紅色的merge線在某些地方已經(jīng)要凝成實體了。這表明在這些版本之間有非常頻繁的code merge。
再補充一下：
這個圖片里面有些地方紅線密集程度有些不大對勁，某些分支幾乎每個版本修改都有被merge。正常開發(fā)中不應(yīng)該是這樣的，通常都只會是某個或某幾個版本被merge。
猜測出現(xiàn)這個情況的可能，有一種解釋就是可能在開發(fā)時使用了某些自動merge的工具，當(dāng)該分支每出現(xiàn)一個新版本時就自動merge到某個目標(biāo)分支，以保證兩個分支代碼的高度一致。當(dāng)然這個無法證實，只是我的一個猜測。
摘要: 這個是發(fā)生在上周周末的真實案例，因為cxf client 端線程安全導(dǎo)致的錯誤，總結(jié)出來希望其他使用cxf的朋友注意。
閱讀全文
摘要: ivy可以非常容易的作為一個單獨的程序使用。你所需要的只是一個java1.4+的運行環(huán)境(JRE)!
閱讀全文
摘要: 使用ivy的主要和最頻繁的方式是在ant構(gòu)建文件中。不過，ivy也可以作為獨立的應(yīng)用被調(diào)用。
閱讀全文
摘要: ivy的使用完全是基于以"ivy文件"著稱的模塊描述符。ivy文件是xml文件，通常被稱為ivy.xml，包含模塊依賴的描述，它發(fā)布的制品和它的配置。
閱讀全文
摘要: 為了如您所想的工作，ivy有時需要一些設(shè)置。實際上，ivy可以在完全沒有任何特殊設(shè)置的情況下工作，查閱默認(rèn)設(shè)置文檔來獲取相關(guān)的更詳盡的信息。但是ivy有能力在完全不同的上下文下工作。你只需要正確的配置它。
閱讀全文
摘要: 安裝ivy主要有兩種方式，手工安裝或者自動安裝。
閱讀全文
摘要: 這里有一些我們從我們的經(jīng)驗和一些客戶的顧問工作中收集到的建議和最佳實踐。
5) 處理集成版本
6) 是否將依賴內(nèi)聯(lián)(inlining)
7) 雇用專家
閱讀全文
摘要: 這里有一些我們從我們的經(jīng)驗和一些客戶的顧問工作中收集到的建議和最佳實踐。
1) 為所有的模塊添加模塊描述符
2) 使用自己的企業(yè)倉庫
3) 至少在組織和模塊上使用模式
4) 為公共倉庫發(fā)布ivysettings.xml
閱讀全文
摘要: 前面已經(jīng)介紹了ivy主要的術(shù)語和概念，現(xiàn)在是時候說明ivy如何工作的了。
閱讀全文
摘要: 在學(xué)習(xí)ivy的過程中陸陸續(xù)續(xù)的翻譯了一些ivy的參考文檔，現(xiàn)在準(zhǔn)備將這個工作進行到底，將官方網(wǎng)站上完整的ivy參考文檔翻譯成中文。上面內(nèi)容是參考文檔的目錄，翻譯完成的部分我會陸續(xù)更新為中文并加入鏈接。
英文文檔地址請見：http://ant.apache.org/ivy/history/latest-milestone/reference.html
水平有限，出現(xiàn)錯誤的地址請多多指正。
閱讀全文
摘要: ivy中引入了一些自己的概念，了解并理會這些概念對ivy的學(xué)習(xí)使用是有幫助的。這里翻譯一下官網(wǎng)的介紹ivy主要概念的文章，原文在此：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因內(nèi)容太長而拆分，下面是第二部分。
閱讀全文
摘要: 日前升級內(nèi)存容量到8g之后，發(fā)現(xiàn)在xp下因為無法全部利用造成浪費，因此考慮安裝ramdisk以充分利用資源。
閱讀全文
摘要: ivy中引入了一些自己的概念，了解并理會這些概念對ivy的學(xué)習(xí)使用是有幫助的。這里翻譯一下官網(wǎng)的介紹ivy主要概念的文章，原文在此：http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因內(nèi)容太長而拆分，下面是第一部分
閱讀全文
在ubuntu 8.10下安裝的svn，在將Ubuntu的語言修改為英文之后，出現(xiàn)錯誤警告：
$ svn
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
Type 'svn help' for usage.
解決方法很簡單，修改/etc/profile：
sudo vi /etc/profile
加入一行：
export LC_ALL=C
source /etc/profile
svn就可以正常工作了。
摘要: 安裝ubuntu 8.10時選擇的語言是中文，結(jié)果發(fā)現(xiàn)在命令行下執(zhí)行命令時，無法正確的顯示中文。
雖然我的英文不怎么樣，但是相比還不至于對付不了這種情況，還是改為使用英文好了。
google一下，非常簡單，記錄下來避免日后遺忘
閱讀全文
摘要: 一直用vmvare跑linux作為開發(fā)測試平臺，但是總是在安裝vmvare tools時遇到問題，懶得再為此浪費時間。
自己動手，豐衣足食，手工安裝吧，
這個應(yīng)該是任何情況下都可以搞的定的方法。
閱讀全文
摘要: ivy中有一套自己特定的術(shù)語，了解并熟悉他們對ivy的使用非常重要，尤其對于ivy新手。
閱讀全文
摘要: 單位一臺服務(wù)器裝了SUSE 企業(yè)版 10，用PUTTY登錄不上去，用SSH Shell卻能登錄上去。
閱讀全文
摘要: 不想用apt直接裝，跑去sun的網(wǎng)站拖了一個jdk6 update13來.
閱讀全文
摘要: 今天在研究couchdb時偶然發(fā)現(xiàn)的一個blog，列舉了當(dāng)前比較不錯的分布式 key-value存儲，并做了很有參考價值的分析，回帖也很有價值。
推薦對分布式存儲有興趣的朋友閱讀， 地址 http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
閱讀全文
從ivy的官網(wǎng)看到，ivy 2.1.0-rc1在3月30號發(fā)布，從名字可以看到這是一個候選發(fā)布/CR版本。
簡單看一下新版本的主要特性：
1. maven2 能力增強，修訂了一些bug，覆蓋更多的pom特性
2. 更多的用于Ivy ant task和命令行的選項
3. 大量的bug修訂，文件在Jira和release文件中
官方的意見是鼓勵所有用戶升級到這個新版本。
在這里可以下載：
http://ant.apache.org/ivy/download.cgi
查了一下上一個大的release版本是2.0.0，在今年1月20號發(fā)布，迄今不到3個月，更新的速度
還是很不錯的。沒有增加新的功能或者特殊的特性，主要還是在改善和maven2的集成以及bug
fix。
最近比較關(guān)注ivy這個小東西，希望能在maven之外多一些選擇，ivy目前的感覺不錯。
剛得到的消息，實驗了一下可以申請成功，有興趣的兄弟趕緊。
新聞出處：
http://www.javaeye.com/news/6754-officially-announced-google-app-engine-to-support-java
由于javaeye申明不容許轉(zhuǎn)載，所以我只能貼出來地址，詳情請自己過去看。
簡單點說：
1. Google App Engine正式宣布支持Java！
2. Google App Engine 提供1萬個名額給感興趣的Java開發(fā)者試用，趕緊注冊：http://appengine.google.com/promo/java_runtime
再簡單介紹一下申請流程：
1. 登錄google賬號，沒有的先申請
2. 有一個短信認(rèn)證的要求，填入自己的手機號碼，比如"+8613900000000"，短信很快的，一般10秒就能下來。
3. 申請app的頁面，注意先別急著填application的id和tilte，先看上面，有一行簡單的提說說要不要試試java版本的GAE，點進去
4. 這里有一個sing up的按鈕，點吧，這個才是真正的申請java版本GAE的地方
5. 成功后會告之收到申請，如何如何。等一會去看gmail，如果成功就會收到一封郵件說account actived。大概3-5分鐘吧。
6. 再去申請app吧，慢慢來
摘要: maven很強大，但是遠(yuǎn)不完美，令人煩惱的地方也不少。看到Ivy似乎日漸成熟，試試看這個小東西表現(xiàn)如何，畢竟后面有那個強大的我喜歡的ant。
折騰了一番，整理出來點東西，分享給對ivy同樣感興趣的朋友。依然是"初學(xué)"系列，提供給新手入門使用。
閱讀全文
摘要: 從http://m2eclipse.sonatype.org/update下在線安裝m2eclipse，現(xiàn)在的版本是0.9.7，20090209的版本，應(yīng)該是新出來的。安裝時出現(xiàn)錯誤提示導(dǎo)致無法安裝：
Cannot complete the request. See the details.
Cannot find a solution satisfying the following requirements org.eclipse.ui.workbench [3.4.2.M20090127-1700].
閱讀全文
摘要: 升級到m2eclipse 0.9.7版本后，發(fā)現(xiàn)一個問題，maven Assembly plugin無法工作，具體是在eclipse下執(zhí)行"run as" --> "maven package"時，報錯：
[INFO] Failed to create assembly: Error adding file 'net.runafter.nptt:NpttCore:jar:0.1.0' to archive:
G:\workspace\private\tools\nptt\trunk\NpttCore\target\classes isn't a file.
可以看到，maven Assembly plugin試圖以操作文件的方式操作目錄NpttCore\target\classes，因此失敗造成整個package命令執(zhí)行失敗。
閱讀全文
摘要: 折騰了好久，終于搞定subversive和svn connector的安裝了，過程很痛苦，因為eclipse的在線安裝實在是太慢了......
最后我的總結(jié)就是不要直接從網(wǎng)上安裝，太慢太慢，會吐血而亡的，我已經(jīng)深刻領(lǐng)略了......
正確的方法是先從官方網(wǎng)站上下載安裝包，然后再用eclipse的software update工具安裝，這樣速度就很快。我的1m的adsl，如果直接網(wǎng)上安裝，大概1k下載速度，直接http下載安裝包，大概在50-100k之間，差別夠大吧？
閱讀全文
摘要: 總結(jié)，建議在使用eclipse安裝插件時，先在Manager Sites中取消其他所有站點！
閱讀全文
摘要: subversion默認(rèn)的diff工具比較簡單，文本界面，在使用時不是很理想。
winmerge則是一款非常優(yōu)秀的diff/merger工具，由于winmerge自帶和clearcase的集成功能，因此我在公司工作環(huán)境下一直都是使用winmerge替代clearcase自帶的diff工具使用了。
近日使用svn，每次執(zhí)行svn diff后都對出來的文本比較結(jié)果的效果不滿意，即使換成TortoiseSVN的diff工具也還是不夠好。因此產(chǎn)生想法，能否將winmerger集成到subversion.
google了一下"winmerge subversion"，順利在國外的一個blog上找到答案，實驗了一下，很成功，效果非常好，現(xiàn)在將具體方法共享出來。
閱讀全文
摘要: 家里的服務(wù)器使用的是subversion1.4的版本，最近發(fā)現(xiàn)1.5已經(jīng)陸續(xù)出現(xiàn)了多個bugfix的小版本更新，考慮到1.5出來時間也比較長了，應(yīng)該已經(jīng)穩(wěn)定下來。而且1.5也帶來了不少新特性，聽聞速度也有所提升，因此考慮升級到最新版本1.5.5。
閱讀全文
摘要: 近期由于公司有意向在未來將目前的一個大型產(chǎn)品從weblogic移植到glassfish，因此提前學(xué)習(xí)glassfish以做好準(zhǔn)備。
首先從下載安裝開發(fā)，學(xué)習(xí)如何搭建glassfish的開發(fā)環(huán)境。
閱讀全文
摘要: 在上一篇文章中，討論到在對maven的機制不熟悉的情況下，為了實現(xiàn)自己需要的打包格式而使用maven ant task以maven + ant的方式來實現(xiàn)非標(biāo)準(zhǔn)打包，而現(xiàn)在要介紹的是maven中針對打包任務(wù)而提供的標(biāo)準(zhǔn)插件：assembly plugin。
閱讀全文
摘要: maven很強大，但是總有些事情干起來不是得心應(yīng)手，沒有使用ant時那種想怎么干就怎么干的流暢感。尤其當(dāng)要打包一個特殊（相對maven的標(biāo)準(zhǔn)架構(gòu)而且）時，常有不知所措的感覺。當(dāng)然這個應(yīng)該和自己對maven的了解不夠有關(guān)，畢竟，“初學(xué)maven”嘛。
但是maven在依賴管理方面實在是太強大了，太喜歡，退回原來的ant方式完全不可能，我想用過maven的人，一般是不會有回到原來在 cvs,subversion中checkin/checkout n個jar包的時代，僅此一項理由就足夠繼續(xù)堅持使用maven了。
然而ant的靈活又難于忘懷，尤其是從ant的build.xml一路走來的人，總是回不知不覺間想到ant的美好。魚與熊掌，我都想要。
閱讀全文