编写build.xml的12个原则

原创 2003年11月06日 00:28:00

我不喜欢这个title的翻译,它的原文应该是“通往build.xml天堂的12条路”。为了让读者更容易理解,我最后还是选择了这个通俗……俗气的title。需要注意的是,这篇weblog来自“fate”hani……

12 paths to build.xml nirvana

1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers.

2 - While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh.

3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file.

4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma.

5 - If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's.

6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help.

7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional.

8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where.

9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know.

10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry.

11 - build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run.

12 - Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves.

build.xml的编写

Ant工具是非常有用的工程部署工具,可以自动编译java项目,自动对文件进行打包,则我们可以只需要提交代码,打包直接执行命令就可以,所以非常实用。Ant工具直接作用到build.xml文件,所以对于b...
  • DFL_always
  • DFL_always
  • 2015年12月07日 18:16
  • 156

Ant:编写build.xml的方法

编写ant:build.xml的方法- -                                        下面是关于ant简介的一篇文章,可以只看build.xml相关的部分。 ...
  • han_huayi
  • han_huayi
  • 2014年04月15日 21:27
  • 512

编写ant:build.xml的方法

Ant:编写build.xml的方法 编写ant:build.xml的方法- -                                        下面是关于ant简介的一篇文章,可...
  • lcathm
  • lcathm
  • 2014年05月31日 20:40
  • 552

ANT及build.xml文档编写

1.什么是构建文件? 构建文件是ant执行工程构建的入门文件,构建的所有任务都必须只能写在构建文件内,构建文件必须是符合标准的xml文件,默认的构建文件为build.xml,当你键入“ant”命名执...
  • Qiurungui
  • Qiurungui
  • 2013年01月10日 11:14
  • 367

ANT及build.xml文档编写

为了批量编译java文件,今天学习了ANT(Another Neat Tool另一个整洁的工具,http://www.apache.org/)及build.xml文档的编写,找了篇文章,先学习模仿~~...
  • smqh2011
  • smqh2011
  • 2013年04月03日 15:44
  • 778

Ant之build.xml配置详解

前言国内关于build.xml的配置资料太零散了,实在是受不了,故而将自己的笔记整理成博文,方便大家查阅和理解。build.xml配置参数构建文件默认叫build.xml,其有很多配置参数。proje...
  • mevicky
  • mevicky
  • 2017年06月01日 10:05
  • 3409

Ant之build.xml详解(有实例)

关键字: ant build.xml Ant的概念  可能有些读者并不连接什么是Ant以及入可使用它,但只要使用通过Linux系统得读者,应该知道make这个命令。当编译Linux内核及一些软件的源...
  • lichardwang
  • lichardwang
  • 2016年10月25日 11:12
  • 804

Jenkins进阶系列之——16一个完整的JENKINS下的ANT BUILD.XML文件

网上看见的,确实很全,该有的基本都覆盖到了。自己拿来稍微改改就可以用了。 注:property中的value是你自己的一些本地变量。需要改成自己的  xml version="1.0"...
  • wangmuming
  • wangmuming
  • 2014年07月10日 17:13
  • 11057

ant的安装、使用,build.xml简单编写

如果没有eclipse集成环境可以自己下载ant http://www.apache.org/ 下载最新的版本 解压ant 后设置ANT_HOME, PATH中添加ANT_HOME目录下的bin...
  • bao19901210
  • bao19901210
  • 2014年04月16日 17:43
  • 18729

Ant集成Junit实现自动化测试的Build.xml模板详解

Apache Ant简介简单的讲,Ant是一个命令行工具,可以用来编译java文件,执行java程序,生成jar文件,执行测试等。Ant主要依赖与一个build.xml的配置文件,下面就是一个buil...
  • qq_28082757
  • qq_28082757
  • 2017年06月01日 16:36
  • 266
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:编写build.xml的12个原则
举报原因:
原因补充:

(最多只允许输入30个字)