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

Question

我最近将系统从Mint12升级到Mint14，并且在使旧项目在新系统上正常工作时遇到了严重问题。总结一下：

• 让Mint14正常运行，并安装了我所有必需的软件（Eclipse，ANT等）
• 从备份磁盘还原了我的文件
• 将Oracle JDK设置为默认Java版本
• 从SVN中签出了我的项目的新副本
• 更新了构建文件中的所有路径以反映新的user_id

一切都很好，但是我的蚂蚁构建似乎已经被搞砸了，所以当我尝试构建项目时，出现以下错误：

~/new_workspace/my_project $ ant dist
Buildfile: /home/my_userid/new_workspace/my_project/build.xml
  [taskdef] Could not load definitions from resource net/sf/antcontrib/antlib.xml. It could not be found.

init:

compile:
    [javac] /home/my_userid/new_workspace/my_project/build.xml:246: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds

static:

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 !

BUILD FAILED
/home/my_userid/new_workspace/my_project/build.xml:104: Can't get status of /home/my_userid/new_workspace/my_project

Total time: 0 seconds

我注意到“太旧了，无法使用工作副本…”，但是当我检查时svn --version发现它是1.7.5，应该还可以。请注意，服务器上的SVN版本未更改。有一种理论认为，该项目（通过Eclipse，使用Subclipse
1.6签出）不适用于ANT通过命令行使用的版本，但是在这种情况下，客户端版本不是太旧，而是太新了！值得“降级” Subversion吗？

否则可能是什么问题，我该如何解决？是否应该检查其他常见问题（在发行版升级/迁移过程中可能会发生），以确保项目能够正常进行？（以下是构建文件的相关位）

该位定义svn绑定

  <path id="svnant.classpath">
    <fileset dir="/home/my_userid/.ant/lib">
      <include name="svnant.jar" />
      <include name="svnClientAdapter.jar" />
      <include name="svnjavahl.jar" />
      <!-- <include name="svnkit.jar" /> tried this as well but no joy -->
    </fileset>
  </path>

“ dist”目标中的相关位：

  <target name="dist"
          depends="compile,static" description="Compiles and builds jar files">

    <mkdir dir="${dist}"/>
    <buildnumber file="project-version.properties"/>
    <property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/>
    <svn>
      <status path="."
              lastChangedRevisionProperty="rev.number" />
     <info target="." />
    </svn>
    ...

Answer 1

我看到第一个问题：

[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。

希望这可以帮助。