#
摘要: 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)!
阅读全文