- 浏览: 45293 次
文章分类
最新评论
转自:http://www2.cs.siu.edu/~rahimi/cs412/slides/What%20is%20Ant%20.htm
What is Ant?
What is Ant? A simple definition might state that Ant is a Java-based build tool. Of course that definition may just raise the question in your mind "What is a build tool?". To answer that question, consider what is required to build a software system. Typically, there is much more to building software than just typing in and then compiling the source code. There is a number of steps required to transform the source into a deployable and useable software solution. The following is a hypothetical build process you might use with a simple software system
1.Get the source. You may need to download or fetch the source from a source code repository. For this, you might need to know the tag or version of the source code you want to build.
2.Prepare a build area. You will probably want to create a set of directories, perhaps according to some standardized directory layout.
3.Configure the build. In this step, you will determine what optional components can be built based on the current environment. You might want to set build numbers and version numbers to be included in the build.
4.Validate the source code. You may have a standard style guide and you wish to ensure all code conforms to this before you build a release.
5.Compile the source code
6.Build the compiled code into libraries potentially including non-code resources such as properties, images and sound files.
7.Run the system's tests to validate the build.
8.Build the documentation for the software. This may range from something as simple as collecting text files up to processing content through some form of publishing system to produce the documentation in its final form
9.Package up all of the components of the software – code, resources, images, documentation, etc. – into a deployable package. You might need to produce several packages in different formats for different target users
10.Deploy the software to some standard location for use or distribution
This is a high-level view of a software build process. A real-life build process may of course require many more and varied steps. Each of these steps may involve many individual operations.
If you try to use a manual process for building your software you would find it to be tedious, error prone and, in general, not very repeatable. You might forget to set the version number or to provide a tar file for Unix users. You might change the directory structure, confusing users who upgrade from the previous version of the software. Even worse, you may forget to test the software and ship a version that may not even work. Such ad-hoc build processes are always a source of problems and the best solution is to automate the build process. The tools you use to automate the build process are known, unsurprisingly, as build tools. Ant is such a tool.
In general, a build tool allows developers and build managers to describe the build process. In a build, some steps may need to be executed before others or they may be independent of others. In the example above, while the steps are laid out as a linear sequence, there are certain dependencies evident. Obviously, the source cannot be compiled until it has been fetched and the directory structure has been built. The directory structure, however, can be created before, or even while the source is being fetched. Fetching the source may be an expensive operation – perhaps accessing a remote server – and you may not want to do that every time you build the software. A build tool helps by only performing the operations that are required.
In summary, a build tool provides a mechanism to describe the operations and structure of the build process. When the build tool is invoked it uses this description, examines the current state of affairs to determine the steps that need to be executed and in which order, and then manages the execution of those steps.
Often developers will start the automation of their build process with scripting tools supplied by the operating system. Depending on your platform that might be a shell script, a batch file, a Perl script or, indeed, whatever scripting language is your particular preference. These scripts can be quite sophisticated but they usually fail to capture the structure of the build process and can often become a maintenance headache. Each time your code is changed, say adding a new source directory, you will need to update the build script. Since the build scripts are ad-hoc, new developers on your team may not understand them. Further, in many instances, such scripts perform all of the steps of a build even when only some are required. That is OK for build managers who will want clean builds but quickly becomes difficult for developers who may do many builds in a development session and need fast, incremental builds.
Java-Based
Those of you who are familiar with make will realize that the above description of a build tool is also satisfied by make. That isn't surprising since make is also a build tool. Makefiles provide the build description and make then organizes the execution of shell commands to build the software. One major difference between Ant and make is that Ant executes tasks implemented as Java classes. Make executes commands from the operating system's shell.
Being Java-based means a few different things for Ant. Ant largely inherits Java's platform independence. This means that Ant's build files can be easily moved from one platform to another. If you can ensure a homogenous build, development and deployment environment for the life of your project, platform independence may not seem important. For many softwre developments, however, development and deployment environments may be quite different. Open source Java projects, for example, have to support a number of target platforms. An Ant build file allows such projects to have and maintain a single build description. Even in closed source developments, the development and deployment platforms may be different. It is not uncommon for the development environments to be PC-based while production may use a Sun or IBM high-end Unix server. If these environments were to use different build descriptions, there is always the possibility, even the inevitability, of these descriptions getting out of sync. You tend to encounter these problems when production deployment fails, perhaps subtly, and it is usually an unpleasant discovery. Using the same build description throughout the project reduces the opportunity for such problems to occur.
Platform independence can sometimes be limiting, so some Ant tasks give access to the facilities of the underlying operating system. That puts the choice in the hands of the build file developers. Even when this is necessary, Ant will allow you to manage the bulk of the build process in a platform independent way, augmented with platform dependent sections.
Another aspect of Ant that is Java-Based is that the primitive build steps, known as tasks in Ant, are built in Java. These tasks can be loaded at runtime, so developers may extend Ant by writing new Tasks. You will also find many of the tasks that come with Ant are written to deal with the typical structure of Java projects. For example, the Java compilation task understands the directory structures involved in the Java package concept. It is able to compile all code in a source tree in a single operation.
Ant and Make
Both Ant and make are build tools. Many people have come to Ant from a make background looking to see what its strengths may be and why would they use Ant in preference to make.
Ant's website, reflecting the comments of James Duncan Davidson, Ant's original author, states that Ant is "like make without make's wrinkles". It turns out that many people are comfortable with make's wrinkles. If you are coming from a make background, you may miss the way make does things. You may wonder how Ant can really be a build tool without doing the things in the same way as make. You need to adopt a different mindset when developing an Ant build file than you would use when developing a Makefile. We'll look at the differences between Ant and make in a later section, once we have explored Ant to the point where such a comparison will make sense.
History of Ant
The following is a brief, albeit incomplete, history of Ant. It will give you a flavor for the evolution of Ant.
Ant started life as a quick hack by James Duncan Davidson to help building Tomcat, which was, at the time, Sun's servlet engine in development. Ant was originally developed on a Windows laptop, which some people find surprising. James was instrumental in the donation of the Tomcat codebase to the Apache Software Foundation by Sun to form the Apache Jakarta project. Included, indeed some might say tucked away, in that donation was Ant. Apparently the name started out as an acronym for "Another Neat Tool".
Ant was added to the jakarta-tools CVS repository on October 9th, 1999. At this time, Ant was still considered part of the Tomcat project. It underwent development as part of the Tomcat project and at around Christmas 1999, Ant was released as a part of Tomcat 3.0. With this release, many people began to see Ant in operation and how it could be used to build software. Already people within the Apache Jakarta and XML projects had begun to use Ant to build other projects besides Tomcat. For example the Xerces XML parser project began using Ant in November 1999.
It became clear, with Ant's increasing popularity, that it was not really suitable to remain a part of Tomcat and that it should become a top level sub-project of the Apache Jakarta project. In February 2000, the code for Ant was moved to its own repository, jakarta-ant, at Apache. After some significant development work, Ant 1.1 was released in July, 2000. This was the first official release of Ant as a separate entity. To avoid confusion with the version released with Tomcat, there was never a 1.0 release of Ant. In the end, the original release as part of Tomcat 3.0 came to be known as Ant 0.3.
In November 2002, The Apache board promoted Ant to a top–level Apache project.
Since that initial release of Ant 1.1, there have been regular updates to Ant
Release Date
Ant 1.1 July 2000
Ant 1.2 October 2000
Ant 1.3 March 2001
Ant 1.4 September 2001
Ant 1.4 October 2001
Ant 1.5 July 2002
Ant 1.5.1 October 2002
Ant 1.5.2 March 2003
With that brief introduction and history, you are ready to begin your exploration of Ant. There will be more Ant turorials to come …
Copyright © 2003, Conor MacNeill. All rights reserved.
What is Ant?
What is Ant? A simple definition might state that Ant is a Java-based build tool. Of course that definition may just raise the question in your mind "What is a build tool?". To answer that question, consider what is required to build a software system. Typically, there is much more to building software than just typing in and then compiling the source code. There is a number of steps required to transform the source into a deployable and useable software solution. The following is a hypothetical build process you might use with a simple software system
1.Get the source. You may need to download or fetch the source from a source code repository. For this, you might need to know the tag or version of the source code you want to build.
2.Prepare a build area. You will probably want to create a set of directories, perhaps according to some standardized directory layout.
3.Configure the build. In this step, you will determine what optional components can be built based on the current environment. You might want to set build numbers and version numbers to be included in the build.
4.Validate the source code. You may have a standard style guide and you wish to ensure all code conforms to this before you build a release.
5.Compile the source code
6.Build the compiled code into libraries potentially including non-code resources such as properties, images and sound files.
7.Run the system's tests to validate the build.
8.Build the documentation for the software. This may range from something as simple as collecting text files up to processing content through some form of publishing system to produce the documentation in its final form
9.Package up all of the components of the software – code, resources, images, documentation, etc. – into a deployable package. You might need to produce several packages in different formats for different target users
10.Deploy the software to some standard location for use or distribution
This is a high-level view of a software build process. A real-life build process may of course require many more and varied steps. Each of these steps may involve many individual operations.
If you try to use a manual process for building your software you would find it to be tedious, error prone and, in general, not very repeatable. You might forget to set the version number or to provide a tar file for Unix users. You might change the directory structure, confusing users who upgrade from the previous version of the software. Even worse, you may forget to test the software and ship a version that may not even work. Such ad-hoc build processes are always a source of problems and the best solution is to automate the build process. The tools you use to automate the build process are known, unsurprisingly, as build tools. Ant is such a tool.
In general, a build tool allows developers and build managers to describe the build process. In a build, some steps may need to be executed before others or they may be independent of others. In the example above, while the steps are laid out as a linear sequence, there are certain dependencies evident. Obviously, the source cannot be compiled until it has been fetched and the directory structure has been built. The directory structure, however, can be created before, or even while the source is being fetched. Fetching the source may be an expensive operation – perhaps accessing a remote server – and you may not want to do that every time you build the software. A build tool helps by only performing the operations that are required.
In summary, a build tool provides a mechanism to describe the operations and structure of the build process. When the build tool is invoked it uses this description, examines the current state of affairs to determine the steps that need to be executed and in which order, and then manages the execution of those steps.
Often developers will start the automation of their build process with scripting tools supplied by the operating system. Depending on your platform that might be a shell script, a batch file, a Perl script or, indeed, whatever scripting language is your particular preference. These scripts can be quite sophisticated but they usually fail to capture the structure of the build process and can often become a maintenance headache. Each time your code is changed, say adding a new source directory, you will need to update the build script. Since the build scripts are ad-hoc, new developers on your team may not understand them. Further, in many instances, such scripts perform all of the steps of a build even when only some are required. That is OK for build managers who will want clean builds but quickly becomes difficult for developers who may do many builds in a development session and need fast, incremental builds.
Java-Based
Those of you who are familiar with make will realize that the above description of a build tool is also satisfied by make. That isn't surprising since make is also a build tool. Makefiles provide the build description and make then organizes the execution of shell commands to build the software. One major difference between Ant and make is that Ant executes tasks implemented as Java classes. Make executes commands from the operating system's shell.
Being Java-based means a few different things for Ant. Ant largely inherits Java's platform independence. This means that Ant's build files can be easily moved from one platform to another. If you can ensure a homogenous build, development and deployment environment for the life of your project, platform independence may not seem important. For many softwre developments, however, development and deployment environments may be quite different. Open source Java projects, for example, have to support a number of target platforms. An Ant build file allows such projects to have and maintain a single build description. Even in closed source developments, the development and deployment platforms may be different. It is not uncommon for the development environments to be PC-based while production may use a Sun or IBM high-end Unix server. If these environments were to use different build descriptions, there is always the possibility, even the inevitability, of these descriptions getting out of sync. You tend to encounter these problems when production deployment fails, perhaps subtly, and it is usually an unpleasant discovery. Using the same build description throughout the project reduces the opportunity for such problems to occur.
Platform independence can sometimes be limiting, so some Ant tasks give access to the facilities of the underlying operating system. That puts the choice in the hands of the build file developers. Even when this is necessary, Ant will allow you to manage the bulk of the build process in a platform independent way, augmented with platform dependent sections.
Another aspect of Ant that is Java-Based is that the primitive build steps, known as tasks in Ant, are built in Java. These tasks can be loaded at runtime, so developers may extend Ant by writing new Tasks. You will also find many of the tasks that come with Ant are written to deal with the typical structure of Java projects. For example, the Java compilation task understands the directory structures involved in the Java package concept. It is able to compile all code in a source tree in a single operation.
Ant and Make
Both Ant and make are build tools. Many people have come to Ant from a make background looking to see what its strengths may be and why would they use Ant in preference to make.
Ant's website, reflecting the comments of James Duncan Davidson, Ant's original author, states that Ant is "like make without make's wrinkles". It turns out that many people are comfortable with make's wrinkles. If you are coming from a make background, you may miss the way make does things. You may wonder how Ant can really be a build tool without doing the things in the same way as make. You need to adopt a different mindset when developing an Ant build file than you would use when developing a Makefile. We'll look at the differences between Ant and make in a later section, once we have explored Ant to the point where such a comparison will make sense.
History of Ant
The following is a brief, albeit incomplete, history of Ant. It will give you a flavor for the evolution of Ant.
Ant started life as a quick hack by James Duncan Davidson to help building Tomcat, which was, at the time, Sun's servlet engine in development. Ant was originally developed on a Windows laptop, which some people find surprising. James was instrumental in the donation of the Tomcat codebase to the Apache Software Foundation by Sun to form the Apache Jakarta project. Included, indeed some might say tucked away, in that donation was Ant. Apparently the name started out as an acronym for "Another Neat Tool".
Ant was added to the jakarta-tools CVS repository on October 9th, 1999. At this time, Ant was still considered part of the Tomcat project. It underwent development as part of the Tomcat project and at around Christmas 1999, Ant was released as a part of Tomcat 3.0. With this release, many people began to see Ant in operation and how it could be used to build software. Already people within the Apache Jakarta and XML projects had begun to use Ant to build other projects besides Tomcat. For example the Xerces XML parser project began using Ant in November 1999.
It became clear, with Ant's increasing popularity, that it was not really suitable to remain a part of Tomcat and that it should become a top level sub-project of the Apache Jakarta project. In February 2000, the code for Ant was moved to its own repository, jakarta-ant, at Apache. After some significant development work, Ant 1.1 was released in July, 2000. This was the first official release of Ant as a separate entity. To avoid confusion with the version released with Tomcat, there was never a 1.0 release of Ant. In the end, the original release as part of Tomcat 3.0 came to be known as Ant 0.3.
In November 2002, The Apache board promoted Ant to a top–level Apache project.
Since that initial release of Ant 1.1, there have been regular updates to Ant
Release Date
Ant 1.1 July 2000
Ant 1.2 October 2000
Ant 1.3 March 2001
Ant 1.4 September 2001
Ant 1.4 October 2001
Ant 1.5 July 2002
Ant 1.5.1 October 2002
Ant 1.5.2 March 2003
With that brief introduction and history, you are ready to begin your exploration of Ant. There will be more Ant turorials to come …
Copyright © 2003, Conor MacNeill. All rights reserved.
相关推荐
1.Introduction 2.Installation of ... 16.2.What is ANT 16.3.Configuration of ANT 16.4.Usage of ANT 17.Conclusions 18.Epilogue: Technical Background about this Document 19.About the Author
16. What is the biggest ant in the world? 这个问题没有标准答案,因为蚂蚁种类众多,但一般认为是收获蚁属的一些种类,如杜氏巨蚁。 17. What is in the middle of the world? 答案:字母"O",在world这个词的...
2. 掌握句子结构:What is it? It’s…。 3. 能够识别不同的昆虫,并进行比较:What is it? It’s… It’s…。 4. 培养学生热爱自然,保护植物的意识。 教学资源: 多媒体设备、教学棒、闪卡等。 教学步骤: 1. ...
**1.1 Maven - What is it?** Apache Maven is a software project management and comprehension tool that primarily targets Java projects. It provides a complete lifecycle for managing a project from ...
Maven是Ant的另一种选择么? 1.7. 比较Maven和Ant 1.8. 总结 2. 安装和运行Maven 2.1. 验证你的Java安装 2.2. 下载Maven 2.3. 安装Maven 2.3.1. 在Mac OSX上安装Maven 2.3.2. 在Microsoft Windows上安装...
- "What is Wu Yifan doing? He’s watching insects.":吴一凡正在做什么?他正在观察昆虫。 - "Are they eating the honey? No, they aren’t.":他们正在吃蜂蜜吗?不,他们没有。 - "Is he taking pictures? Yes...
- What is Mike doing? 迈克在做什么? - He's watching insects. 他在观察昆虫。 - Are you eating lunch? 你们在吃午饭吗? - No, we aren't. 不,我们没吃。 - Are they eating the honey? 它们在吃蜂蜜吗?...
Ant是一个Java编写的自动化构建工具,它可以帮助我们自动化构建流程,包括编译、打包等操作,使得整个开发流程更加高效。将Ant与Selenium结合,可以有效地管理测试脚本的构建和执行过程,使其自动化。 TestNG是一个...
8. 更大的:bigger - 比较大小,如:The elephant is bigger than the ant. 9. 更小的:smaller - 强调尺寸或容量较小,如:This room is smaller than our classroom. 10. 更强壮的:stronger - 描述力量或体格,如...
- **词汇**:hello, what’s, your, name, my, children, what, is, hi, morning, goodbye, apple, ant, ball, baby, boy, cat, carrot, deer, dog, door。这些词汇包含了问候、个人属性和一些常见的物品名词。 - ...
- what: 询问事物,例如:What is this? - who: 询问人,例如:Who is that man? - where: 询问地点,例如:Where is the library? - why: 询问原因,例如:Why are you sad? - when: 询问时间,例如:When ...
on the market covering specific topics like Java, J2EE, EJB, Design Patterns, ANT, CVS, Multi-Threading, Servlets, JSP, emerging technologies like AOP (Aspect Oriented Programming), Test Driven ...
* 句子结构:This is a/an [名词]. 第10页:阅读理解 * 学习单词:carrot, dog, elephant, fox, egg * 句子结构:A [名词]. 第11页:听力练习 * 学习单词:√××√√× * 句子结构:听力选择题 第12页:听力...
What is Web Services? Web Services 是一种基于网络的应用程序架构,允许不同的应用程序通过网络进行通信和交互。Web Services 使用标准的协议和格式来描述、发布和发现服务,例如 SOAP、WSDL 和 UDDI。 使用 ...
接下来是了解的词汇,包括名词如mice(老鼠的复数)、grass(草坪)、ant(蚂蚁)、mud(泥)和everyone(每个人),动词如chase(追赶)、hurt(使受伤)、should(应该)、feel(觉得;感到)、sit(坐)、hear...
Ant is a popular build tool for Java projects. You can use Ant to compile and run Groovy scripts by defining a task that calls `groovyc` and `java`. This approach is useful for integrating Groovy ...
1. 名词:如mice(老鼠),grass(草坪),ant(蚂蚁),mud(泥),everyone(每个人)扩大了学生的词汇量,使他们能够描述更丰富的生活场景。 2. 动词:chase(追赶),hurt(使受伤),should(应该),feel...
",询问颜色用 "What color is your rabbit?",询问远处物体用 "What’s that?",告别语用 "Goodbye!",表示喜欢红色苹果用 "I like red apples",初次见面表示愉快用 "Nice to meet you."。 通过这份试卷,教师...