升级 *** 作系统后使我的ANT版本无法正常工作的问题

升级 *** 作系统后使我的ANT版本无法正常工作的问题

我看到第一个问题：

[taskdef] Could not load definitions from resource net/sf/antcontrib/antlib.xml. It could not be found.

这告诉我您

<taskdef>

在

build.xml

文件中的某些位置执行了一项任务，并且该任务无法再找到丢失的可选Ant jar。

我的理论 ：在旧的Ant版本下

$ANT_HOME/lib

，您安装了Ant-Contrib
jar。由于

$CLASSPATH

默认情况下该目录位于Ant的目录中，因此您无需在

<taskdef>

任务行中指定它，因此它看起来像这样：

<taskdef resource="net/sf/antcontrib/antcontrib.properties"/>

我总是建议您始终将这些可选任务jar放入项目中。这样，由于它们已经在项目中，因此无需 安装 这些jar即可使其工作：

• 创建一个目录

  /home/my_userid/new_workspace/my_project/antlib/ac

  ，这样您的项目中就会有一个目录

  antlib/ac

  。
• 在此目录中，下载并安装ant-contrib-1.03.jar
• 现在，将您的

  <taskdef>

  jar 更改为包含在其classpath中。

它看起来应该像这样：

<property name="antlib.dir"       value="${basedir}/antlib"/><property name="ant-contrib.lib"  value="${antlib.dir}/ac"/><taskdef resource="/net/sf/antcontrib/antlib.xml">    <classpath>        <fileset dir="${ant-contrib.lib/>    </classpath></taskdef>

添加

antlib/ac/ant-contrib-1.03b.jar

到您的项目。这样，如果有人签出您的项目，即使他们没有下载并在其计算机上安装ant-
contrib jar，它也会生成。

请注意，我使用的

ant.xml

不是

antcontrib.properties

。这使我可以访问

<for/>

任务而不是较早的

<foreach>

任务。整个内容在此“
Ant-Contrib安装”页面上进行了说明。

---

现在另一个错误：

dist:      [svn] <Status> started ...      [svn] svn: This client is too old to work with working copy '/home/my_userid/new_workspace/my_project'; please get a newer Subversion client      [svn] svn: This client is too old to work with working copy '/home/my_userid/new_workspace/my_project'; please get a newer Subversion client      [svn] <Status> failed !

首先，真正的问题是您的Subversion客户端版本实际上是 太新了 而不是 太旧了
。Ant内部的Subversion正在使用

svnjavahl.jar

客户端，该客户端可能希望使用Subversion工作目录的旧1.6版本。同时，您已签出的Subvfersion客户端版本正在使用
较新的 1.7版本。Eclipse可以通过安装JavaHL，SVNKit甚至使用命令行客户端来执行Subversion检出。

查看已检出目录的目录结构，看看那些臭名昭著的

.svn

目录是分散在每个目录中还是仅分散在根目录中。如果该

.svn

目录仅位于工作目录的根目录下，则您有一个1.7.x版本的Subversion进行检出，而Ant正在使用的Subversion
jar则需要较早的工作目录1.2至1.6.x版本。如果确实看到这些

.svn

目录分散在整个工作目录中，则您的初始签出使用的是旧的工作目录版本，而Ant使用的是新版本。

因此，这是任何情况下的解决方案： 从

build.xml

文件中删除整个Subversion提交内容。首先，它是一个 构建文件
，不应在版本控制系统中进行任何更改。那是不好的形式。更改只应在用户希望时进行，而不是因为他们无意中执行了build.xml文件。

第二，您不应将派生的构建输出存储在存储库中。仅存储源，不存储派生的东西。相反，使用诸如Jenkins之类的构建系统来为您处理整个构建和分发业务。

在版本控制中保存发行版对您没有任何好处。您无法查看分发历史记录，也无法了解所做的更改。您无法在发行版的两个版本之间进行区分，也无法查看更改。您能说的最好的是，这是一个方便的查找位置。问题在于，每次执行新版本时，发行版都会占用大量空间，过一会儿，您将不再拥有大多数发行版。在Subversion中，没有简单的方法来删除它们，因此它们只是开始占用大量空间。

假设您每天存储的存储量为100Mb。假设每年有200个构建（周末或节假日没有构建），并且您每年在存储库中增加2Gb的空间。

使用Jenkins，您可以将发行版本存储在Jenkins内部版本中，Jenkins甚至会自动为您删除较旧的，不重要的发行版本。现在，该发行版与使用它的内部版本相关联，您可以看到各个内部版本之间的差异。

但是，如果这些发行版是其他项目需要的jar文件，该怎么办？使用Ivy等依赖关系管理系统以及Nexus或Artifactory等本地Maven存储库进行管理。

即使您不想走那么远，您仍然可以

<get/>

直接使用Jenkins
的任务拉出所需的罐子。Jenkins为您提供了最后一个好的工件链接，并且可以在构建系统中使用它来提取所需的jar。

希望这可以帮助。