典型的 ant 构建文件中有哪些默认目标?

发布于 2024-08-27 15:30:37 字数 413 浏览 2 评论 0原文

您创建的所有 build.xml 文件是否包含一些预定义的目标集? ,很多 ant 手册建议使用以下目标列表:

  • 一生
  • cleancompilebuildjartestjavadocdistdeploywebapp
  • 例如
  • init
  • 最大
  • 遇到

的构建文件是什么 它有多少个目标?它们是什么?您多久需要一组预定义的目标?

目标是开发一些约定,为任何具有类似 Maven 方法概念的项目提供标准的构建文件模板(当大量工作在幕后进行时,约定优于配置)。另外,如果您知道在哪里可以找到不同构建文件的集合以供选择或从中获得灵感,那就太好了。

Do you have some predefined set of targets which all build.xml files you create contain?
For example, a lot of ant manuals suggest the following list of targets:

  • init
  • clean
  • compile
  • build
  • jar
  • test
  • javadoc
  • dist
  • deploy
  • webapp

What is the most large build file you met in your life? How many targets did it have and what are they? How often do you need more than predefined set of targets?

The goal is to develop some conventions to have standard buildfile template for any project having the notion of the maven-like approach in mind (when a lot of work happens under the cover, convention over configuration). Also it would be great if you know the place where one can find collection of different buildfiles to choose or to get inspired from.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

倦话 2024-09-03 15:30:37

我还在所有 ant 文件中使用这些目标

  • init
  • cleancompile
  • 构建
  • build
  • test
  • javadoc

目标总是创建工件,无论它是 jar 还是 war 或其他什么。

您还应该在约定中包含结构性内容,例如所有库的共享存储库(由某些 VCS 进行版本控制)。
另一件事是为你的 jar 版本 ig 定义属性:

lib.commons-collections=commons-collections-2.1.jar
lib.commons-io=commons-io-1.4.jar

所有 ant 文件中都会引用这些属性,common.jar 是放置工件的地方,以防其他项目依赖它们。

<path id="local-cp">
    <pathelement path="${dir.common.jar}/${lib.shared}" />
    <pathelement path="${dir.lib}/${lib.commons-logging}" />
    <pathelement path="${dir.lib}/${lib.commons-io}" />
...

对于部署,我使用另一组 ant 文件deploy_组件名称.xml
使用 ant 多年后,我建议限制目标数量,有时您可能需要更多步骤来生成代码等。

要了解其他人如何处理更大的项目,您可以下载应用程序服务器的源代码分发以检查他们的工作方式这份工作。

I also use these targets in all ant files

  • init
  • clean
  • compile
  • build
  • test
  • javadoc

The build targets always creates the artefact, no matter whether it is a jar or war or whateveer.

You should also include structural things in your conventions like a shared repository for all libraries (versioned by some VCS).
Another thing would be to define properties for your jar versions i.g.:

lib.commons-collections=commons-collections-2.1.jar
lib.commons-io=commons-io-1.4.jar

which are referenced in all ant files, common.jar is a place where artifacts are placed in case other projects depend on them.

<path id="local-cp">
    <pathelement path="${dir.common.jar}/${lib.shared}" />
    <pathelement path="${dir.lib}/${lib.commons-logging}" />
    <pathelement path="${dir.lib}/${lib.commons-io}" />
...

For deployment I use another set of ant files deploy_component-name.xml
After years with ant I would recommend to keep the number of targets limited, sometimes you may have a few more steps for code generation etc.

To see how others handle bigger projects you could download the source distribution of an application server to examine how they do this job.

小鸟爱天空丶 2024-09-03 15:30:37
  • int
  • 构建
  • jar
  • 部署
  • 清理
  • 测试
  • int
  • build
  • jar
  • deploy
  • package
  • clean
  • test
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文