操作系统升级后让我的 ANT 构建工作的问题 [英] Problems getting my ANT builds to work after OS upgrade

问题描述

我最近将系统从 Mint12 升级到 Mint14，但在让我的旧项目在新系统上正常运行时遇到了严重的问题.总结一下:

• 让 Mint14 运行良好并安装了我所有的基本软件(Eclipse、ANT 等)
• 从我的备份磁盘恢复了我的文件
• 将 Oracle JDK 设置为默认 Java 版本
• 从 SVN 签出我的项目的新副本
• 更新了构建文件中的所有路径以反映新的 user_id

这一切都很好，但我的 ant 构建似乎已经搞砸了，不知何故，当我尝试构建我的项目时，我收到以下错误:

~/new_workspace/my_project $ ant dist构建文件:/home/my_userid/new_workspace/my_project/build.xml[taskdef] 无法从资源 net/sf/antcontrib/antlib.xml 加载定义.无法找到.在里面:编译:[javac]/home/my_userid/new_workspace/my_project/build.xml:246: 警告: 'includeantruntime' 未设置，默认为 build.sysclasspath=last;为可重复构建设置为 false静止的:分布:[svn] <状态>开始了……[svn] svn:此客户端太旧，无法使用工作副本/home/my_userid/new_workspace/my_project"；请获取更新的 Subversion 客户端[svn] svn:此客户端太旧，无法使用工作副本/home/my_userid/new_workspace/my_project"；请获取更新的 Subversion 客户端[svn] <状态>失败的 ！构建失败/home/my_userid/new_workspace/my_project/build.xml:104: 无法获取/home/my_userid/new_workspace/my_project 的状态总时间:0秒

我注意到太旧而无法使用工作副本..."但是当我检查 svn --version 时，我发现它是 1.7.5，应该没问题.请注意，服务器上的 SVN 版本同时没有改变.一种理论是该项目(通过 Eclipse 签出，使用 Subclipse 1.6)不适用于 ANT 通过命令行使用的版本，但在这种情况下，客户端版本不是太旧，而是太新！?是否值得降级"Subversion?

否则可能是什么问题，我该如何解决?是否还有其他常见问题(可能在发行版升级/迁移期间发生)我应该检查以确保项目正常工作?(以下是构建文件的相关部分)

<小时>

该位定义了 svn 绑定

 <fileset dir="/home/my_userid/.ant/lib"><include name="svnant.jar"/><include name="svnClientAdapter.jar"/><include name="svnjavahl.jar"/><!-- <include name="svnkit.jar"/>也试过这个，但没有快乐--></文件集></路径>

dist"目标中的相关位:

 <mkdir dir="${dist}"/><buildnumber file="project-version.properties"/><property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/><svn><状态路径=."lastChangedRevisionProperty="rev.number"/><信息目标=."/></svn>...

解决方案

我看到第一个问题:

[taskdef] 无法从资源 net/sf/antcontrib/antlib.xml 加载定义.无法找到.

这告诉我您在 build.xml 文件中的某个位置有一个 任务，并且它无法再找到丢失的可选 Ant罐子.

我的理论:在 $ANT_HOME/lib 下的旧 Ant 版本中，您安装了 Ant-Contrib jar.由于这个目录默认在 Ant 的 $CLASSPATH 中，你不必在你的 <taskdef> 任务行中指定它，所以它看起来像这样:

我始终建议您始终将这些可选任务 jar 放入您的项目中.这样，没有人必须安装这些 jars 才能让它们工作，因为它们已经在项目中了:

• 创建一个目录/home/my_userid/new_workspace/my_project/antlib/ac，这样你的项目就会有一个目录antlib/ac.
• 在这个目录下，下载安装ant-contrib-1.03.jar
• 现在更改您的 以将此 jar 包含在其类路径中.

它应该是这样的:

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

将 antlib/ac/ant-contrib-1.03b.jar 添加到您的项目中.这样，如果有人检查您的项目，即使他们没有下载 ant-contrib jar 并将其安装到他们的机器中，它也会构建.

注意我使用的是 ant.xml 而不是 antcontrib.properties.这使我可以访问 任务，而不是旧的 任务.Ant-Contrib 安装页面上解释了整个过程.><小时>

现在出现另一个错误:

区:[svn] <状态>开始了……[svn] svn:此客户端太旧，无法使用工作副本/home/my_userid/new_workspace/my_project"；请获取更新的 Subversion 客户端[svn] svn:此客户端太旧，无法使用工作副本/home/my_userid/new_workspace/my_project"；请获取更新的 Subversion 客户端[svn] <状态>失败的 ！

首先，真正的问题是您的 Subversion 客户端版本实际上太新而不是太旧.Ant 内部的 Subversion 正在使用 svnjavahl.jar 客户端，它可能需要旧的 1.6 版本的 Subversion 工作目录.同时，您已检出的 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 和本地 Maven 存储库，如 Nexus 或 Artifactory 来管理它.>

即使您不想走那么远，您仍然可以使用 <get/> 任务直接从 Jenkins 中提取所需的 jar.Jenkins 为您提供了最后一个好的工件链接，这可以在您的构建系统中用于拉取您想要的 jar.

希望这会有所帮助.

I recently upgraded my system from Mint12 to Mint14 and had severe issues with getting my old projects to work nicely on the new system. To summarize it all:

• Got Mint14 to work nicely and installed all my essential software (Eclipse, ANT etc)
• Restored my files from my backup disk
• Set up Oracle JDK as the default java version
• Checked out a fresh copy of my project from SVN
• Updated all paths in the build file to reflect the new user_id

That's all good but my ant build seems to have been messed up, somehow, such that when I try to build my project I get the following error:

~/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

I took notice of the "too old to work with working copy..." but when I check svn --version I see that it's 1.7.5 which should be alright. Note that the SVN version on the server has not changed meanwhile. A theory is that the project (checked out via Eclipse, using Subclipse 1.6) doesn't work with the version ANT uses via command line, but in that case the client version is not too old, but rather too new!? Would it be worth "down-grading" Subversion?

Otherwise what could to be the problem and how can I solve it? Are there other common issues (that might occur during distro upgrade/migration) which I should check in order to make sure the project works as it should? (Below are the relevant bits of the build file)

---

This bit defines the svn bindings

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

The relevant bit in the "dist" target:

  <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>
    ...

解决方案

I see the first problem:

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

This is telling me that you have a <taskdef> task some where in your build.xml file, and that it can no longer find the missing optional Ant jar.

My theory: In your old Ant version under $ANT_HOME/lib, you installed the Ant-Contrib jar. Since this directory is in Ant's $CLASSPATH by default, you didn't have to specify it in your <taskdef> task line, so it looks like this:

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

I always recommend that you always put these optional task jars into your project. This way, no one has to install these jars in order for them to work since they're already in the project:

• Make a directory /home/my_userid/new_workspace/my_project/antlib/ac, so your project will have a directory antlib/ac in it.
• In this directory, download and install ant-contrib-1.03.jar
• Now change your <taskdef> to include this jar in its classpath.

It should look like this:

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

Add antlib/ac/ant-contrib-1.03b.jar to your poroject. This way, if someone checks out your project, it builds even if they didn't download and install the ant-contrib jar into their machine.

Note I'm using ant.xml and not antcontrib.properties. This gives me access to the <for/> task instead of the older <foreach> task. The whole thing is explained on this Ant-Contrib Installation page.

---

Now the other error:

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 !

First, the real issue is that your client version of Subversion is actually too new and not too old. Subversion inside of Ant is using the svnjavahl.jar client which probably wants the old 1.6 version of the Subversion working dirctory. Meanwhile, the version of the Subvfersion client you have checked out is using the newer 1.7 version. Eclipse can do Subversion checkouts by installing JavaHL, SVNKit, or even using the command line client.

Take a look at the directory structure of your checked out directory and see if those infamous .svn directories are scattered in each directory or just in the root directory. If the .svn directory is only under the root directory of your working directory, you have a 1.7.x version of Subversion doing the checkout and your Subversion jar that Ant is using wants the older 1.2 to 1.6.x version of the working directory. If you do see those .svn directories scattered throughout your working directory, then your initial checkout is using the old working directory version and Ant is using the new version.

So, here is the solution in any case: Remove the whole Subversion commit stuff from your build.xml file. First of all, it's a build file, and should not be doing any sort of changes in your version control system. That's bad form. Changes should only be done when the user wants them to, and not because they executed the build.xml file without thinking.

Second of all, you should not be storing derived build output in your repository. Only store the source, and not stuff that's derived. Instead, use a build system like Jenkins to handle the whole build and distribution business for you.

Saving distributions in version control isn't doing you any good. You can't look at the distribution history and understand what changes were made. You can't do a diff between two versions of the distribution and see the changes. The best you can say is that it's a convenient place to find it. The problem is that distributions take a lot of room every time you do a new version, and after a while, you don't most of them any more. In Subversion, there's no easy way to remove them, so they just start taking up a ton of space.

Let's say you have a modest distribution of 100Mb that you're storing for your daily builds. Assume 200 builds per year (no builds on Weekends or holidays) and you're adding 2Gb of space to your repository per year.

With Jenkins, you can store your distributions inside the Jenkins builds, and Jenkins will even remove older, unimportant distributions automatically for you. The distribution is now associated with the build that used it, and you can see the differences between the builds.

But, what if these distributions are jar files that other projects need? Use a dependency management system like Ivy and a local Maven repository like Nexus or Artifactory to manage it.

Even if you don't want to go that far, you could still pull the required jars using the <get/> task directly from Jenkins. Jenkins supplies you with the last good artifact link, and this could be used in your build system to pull the jars you want.

Hope this helps.

这篇关于操作系统升级后让我的 ANT 构建工作的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！