2009年5月31日
#
摘要: 如题,osgi 资料收集贴,随时收集,随时更新。
阅读全文
摘要: 在讨论这个问题前,先简单的介绍一下双重解析器的工作原理:顾名思义,双重解析是双重的:它由一个ivyResolver和一个 artifactResolver组成,其中ivyResolver负责解析ivy的模块描述符,而artifactResolver则用于解析制品。换言之,ivyResolver用来指明需要什么,而artifactResolver则负责获取具体的制品文件。
第一次在学习ivy的过程中看到ivy中的双重解析器,就感觉设计非常的不错,可以比较好的解决这方面的问题。只要维护好ivyResolver中的依赖,则整个系统中的依赖都被限制在这个范围中。比如如果有人想用spring2.5.6之外的版本,哼哼,ivyResolver解析器会不工作的......
但是,在实际的使用过程中发现,双重解析器的工作模式有点问题:如果目标依赖在ivyResolver中可以找到则情况正常,但是如果目标依赖在 ivyResolver中没有定义,ivy居然会在artifactResolver的继续查找!然后报告说依赖解析成功已下载云云,而不是我
阅读全文
摘要: 在maven中,对于一个依赖,除了groupId,artifactId,version这三个属性来作为标志之外,还有一个特殊的属性可用: classifier。
ivy中依赖对应的有属性org,name,rev,分别对应到maven中的groupId,artifactId,version.
但是dependency没有和maven的classifier属性相对应的属性,因此无法表示dependency的classifier。这样就出现问题了,比如上面的testng 的例子,在ivy中如果将对testng的依赖定义写成上面的样子,则解析时是无法获取到我们想到的依赖 testng-5.10.jar的。
那么,在ivy中如何指定classifier属性呢?
阅读全文
摘要: 如果你已经成功的跟随并理解了所有的教程,可能你还是需要得到更好的关于如何在现实世界中只用ivy的描述。
这里有一些有关系的链接.
阅读全文
摘要: 现在你已经看到从一个已经存在的仓库创建你自己的仓库是如何的简单,你可能会想知道如何处理更加复杂的情况,例如当源仓库和目的地仓库不遵循相同的命名约定。
当你有一个已经存在的仓库并且希望从大量的不遵循相同的命名转换的公共仓库中获益时,这个问题非常常见。或者仅仅是因为你发现你作为基础使用的仓库不够一直- 为什么所有的apache commons模块不适用org.apache.commons 组织?历史原因。但是如果你安装你自己的仓库,你可能不想从历史中蒙受损失。
幸运的是,对于这种问题ivy有一种非常强大的答复:namespaces.
阅读全文
摘要: 在这个步骤中我们使用install任务来从maven2 仓库安装模块到一个基于文件系统的仓库。我们首先安装一个不带依赖的模块,然后安装一个带有依赖的模块。
阅读全文
摘要: install任务让你从一个仓库复制一个模块或者模块集合到另一个仓库。这对于构建和维护一个企业或者团队仓库非常有用。如果你不想你的团队中的开发人员都访问公共的maven2仓库(例如为了控制哪些模块可以在你的公司或者你的团队中使用),答复开发人员的请求来手工增加新的模块或者新的版本在某些时候变得令人厌烦。
幸运的是install任务可以在这里提供帮助: 你可以为你的用于维护目标企业仓库的仓库维护构建使用特定的设置。这些设置将指向另一个仓库(例如maven2 公共仓库),因此你只需要使用简单的命令行要求ivy安装你需要的模块。
为了演示这个我们将首先使用个一些基本的ivy设置文件来展示它是如何工作的,然后我们将使用高级命名空间特性来演示如何在源仓库和目标仓库之间处理命名不匹配。
阅读全文
摘要: 这个教程介绍ivy文件中的模块配置的使用。ivy模块配置事实上是一个非常重要的概念。某些人甚至告诉我使用ivy而不用ivy配置就像吃乳酪而不动就在你旁边的Chateau Margaux 1976!
严肃的说,ivy中的配置可以更好的理解为你的模块的视图,你将可以看到在这里他们将如何被高效地使用。
阅读全文
摘要: 在上一个教程中,你已经看到如何处理两个简单项目之间的依赖。
这个教程将引导你完成在一个更加复杂的环境下的ivy使用。这个教程的所有源文件在ivy发行包的src/example/multi-project下可以得到。
阅读全文
摘要: 这个示例将举例说明在两个项目之间的依赖。
depender项目声明它使用dependee 项目。我们将阐明两个事情:
* 被独立的项目声明的公共类库将被依赖的项目自动获取
* depender项目将获取dependee项目的"最新"版本
阅读全文
摘要: 在一些情况下,会发生这样的事情:你的模块描述符(ivy文件,maven pom, ...)被放置在一个地方,而模块的制品(jars,...)在另外一个地方。
双重解析器用于满足这种类型的需求,而这个教程将展示如何使用它。
阅读全文
摘要: 这个例子演示模块是如何被多解析器获得的。使用多解析器在很多情况下是非常有用的,这里是一些例子:
* 来自发行的单独的集成构建
* 为第三方模块使用公共仓库并且为内部模块使用私有仓库
* 使用一个仓库来存储那些在无法管理的公共仓库里里面的不清晰的模块
* 使用本地仓库来暴露在一个开发人员的位置上生成的构建
在ivy中,多解析器的使用是通过一个名为解析器链的复合解析器来支持的。
在我们的例子中,我们将简单的展示如何使用两个解析器,一个在本地仓库而另一个使用maven2仓库。
阅读全文
摘要: 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)!
阅读全文
摘要: 使用ivy的主要和最频繁的方式是在ant构建文件中。不过,ivy也可以作为独立的应用被调用。
阅读全文
摘要: ivy的使用完全是基于以"ivy文件"著称的模块描述符。ivy文件是xml文件,通常被称为ivy.xml,包含模块依赖的描述,它发布的制品和它的配置。
阅读全文
摘要: 为了如您所想的工作,ivy有时需要一些设置。实际上,ivy可以在完全没有任何特殊设置的情况下工作,查阅默认设置文档来获取相关的更详尽的信息。但是ivy有能力在完全不同的上下文下工作。你只需要正确的配置它。
阅读全文
摘要: 安装ivy主要有两种方式,手工安装或者自动安装。
阅读全文
摘要: 这里有一些我们从我们的经验和一些客户的顾问工作中收集到的建议和最佳实践。
5) 处理集成版本
6) 是否将依赖内联(inlining)
7) 雇用专家
阅读全文
摘要: 这里有一些我们从我们的经验和一些客户的顾问工作中收集到的建议和最佳实践。
1) 为所有的模块添加模块描述符
2) 使用自己的企业仓库
3) 至少在组织和模块上使用模式
4) 为公共仓库发布ivysettings.xml
阅读全文
摘要: 前面已经介绍了ivy主要的术语和概念,现在是时候说明ivy如何工作的了。
阅读全文
摘要: 在学习ivy的过程中陆陆续续的翻译了一些ivy的参考文档,现在准备将这个工作进行到底,将官方网站上完整的ivy参考文档翻译成中文。上面内容是参考文档的目录,翻译完成的部分我会陆续更新为中文并加入链接。
英文文档地址请见:http://ant.apache.org/ivy/history/latest-milestone/reference.html
水平有限,出现错误的地址请多多指正。
阅读全文
摘要: ivy中引入了一些自己的概念,了解并理会这些概念对ivy的学习使用是有帮助的。这里翻译一下官网的介绍ivy主要概念的文章,原文在此:http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因内容太长而拆分,下面是第二部分。
阅读全文
摘要: 日前升级内存容量到8g之后,发现在xp下因为无法全部利用造成浪费,因此考虑安装ramdisk以充分利用资源。
阅读全文
摘要: ivy中引入了一些自己的概念,了解并理会这些概念对ivy的学习使用是有帮助的。这里翻译一下官网的介绍ivy主要概念的文章,原文在此:http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因内容太长而拆分,下面是第一部分
阅读全文