Ant: Applications in large-scale applications

Applications of large scale usually mean:

1. Many directories with Deep Layers

2. Third-party ant tasks dependent on scripts, third-party libraries dependent on projects, etc.

3. There are many tests, and the build time feedback period is long.

4. Run on different operating systems

5. Run on machines of different team members

6. Due to the above reasons, the ant script is too long

1. Many directories with Deep Layers

There are usually two styles of solutions

1. First, use <foreach> In ant-contrib to traverse sub-directories and call the build scripts in sequence. Generally, the default target

2. The other is to use ant's <subant> command to search for build scripts and call specific targets.

The first scheme can be considered as depth-first. Different subdirectories are usually different components of the system. This approach is to build a single component and then build another component.

The second solution can be seen as a breadth-first solution. Similar to the template method, each subsystem's build script must define a specific agreed target. The root build script will first call a target of all build scripts, call another target

Of course, you can also use <foreach> to implement the second style.

2. There are many dependencies. The third-party ant task on which the script depends, the third-party library on which the project depends, and so on.

1. Clearly differentiate between build script dependencies and your project dependencies. third-party ant tasks are usually used only during the build process, instead of products, such as checkstyle and Emma, and placed in separate directories, ignore them during packaging. for more information about how to differentiate dependencies, see <cruisecontrol enterprise best practices (2): Keep your dependencies to yourself>

2. Use Ivy to manage dependencies of your project

3. Clear unnecessary dependencies or interference:

1. Always provide <clean> Target and use tools to ensure that the target can always be executed at the required time. For more information, see the following section.

2. Define a separate directory to store all the output of the project. Normally, the directory under the top-level directory is called target, build, or Dist. The internal hierarchy should be consistent with the directory structure of the source file.

3. During the build process, copy the required resources to the output directory defined above, instead of directly operating on the resources.

3. There are many tests and the build feedback period is long.

Generally, you do not want a task to fail until the end of the build process. After correction, you have to run the verification again from the beginning. There are several ways to shorten the feedback time.

1. One is to run the most likely failed task first, using the <subant> or <foreach>

2. One is to define a separate target for each task, or use "property" to select or ignore a specific target. see the IF/Unless attribute of target and the condition element. if you use property to control whether to run all tests or a test:

<JUnit...>

<! --... -->

<Test name = "$ {testcase }"If = "testcase"/>

<Batchtest todir = "$ {test. Data. dir }"Unless = "testcase">

<Fileset dir = "$ {test. classes. dir}" includes = "**/* test. Class"/>

</Batchtest>

</JUnit>

In addition, you want to discover as many problems as possible at one build, instead of stopping the build after the first problem occurs. In this way, you can fix them in batches and then re-run the build, instead of running the build over and over again to identify errors one by one

1. You can use haltonerror, haltonfailure, and errorproperty provided by some tasks to control the build End Time and final results, such:

<JUnitHaltonerror = "false" haltonfailure = "false" errorproperty = "test. Failed" failureproperty = "test. Failed"...>
 

 
<! --... -->
 

 
</JUnit>
 

 
<FailIf = "test. Failed"> Tests failed. Check log or reports for details </fail>
 

4. Run on different operating systems

1. Use the <exec> OS or osfamily attribute to control behaviors on different operating systems

2. Uniform use of path separators "/"

5. It is required to run on machines of different team members, and the environment of each person is different.

In fact, this is a problem of Configuration Management. All documents and dependencies of the project, including ant itself, should be included in a single directory and checked in to the version control system. the relative path is used for all locations involving the path. in this way, the project can be copied and used immediately.

However, there are always some dependencies on the external environment. This requires ant's powerful and reasonable immutable property system.

1. Property is used to reference all possible changes

2. Prioritize the use of JVM system attributes rather than Environment Variables

3. Use the user. properties file to define environment-related properties.<Property File= "$ {User. Home}/User. Properties"/>

4. After user. properties is introduced, a reasonable default value is defined for all properties to handle the absence of incomplete user. properties.

5. <Propertyfile> can also be used in the next two steps.

An application can input user names and passwords in the command line instead of writing them in the script, which avoids security and privacy issues.

Other examples include using property to define test filter, or defining whether to exit or continue to run the build upon the first error.

About directory Processing

1. Define properties for the root directory, and define properties for sub-directories as the starting point

2. Always use$ {Basedir}As the prefix of the relative path. This ensures that all relative paths are correct even if the ant working path is different and the correct basedir attribute is passed.

3. UseLocationDefine a path, instead of value. Ant, expands location into an absolute path, so that its value will not change even if it is passed to another ant project.

6. The ant script is long due to the above reasons

Ant is not a script language. You should be more like writing a product.CodeTake the writing style seriously.

1. As mentioned above, the target for execution is controlled through the command line parameters. If there are too many parameters, you must have usage, help

 
<Target name = "usage">
 

 
<Echo message = "execute 'Ant A' for A."/>
 

<Echo message = "execute 'Ant B 'for B."/>
 

 
<Echo message = "execute 'Ant-Dtest. Filter = **/* seleniumtest. class' for specific test cases."/>
 

 
<Echo message = "execute 'Ant-dsome. Property = XXX' for XXX."/>
 

 
</Target>
 

 
<Target name = "help" depends = "usage"/>
 

2. Modular build script, using <macrodef>, etc.

3. Attackers can extract reusable macrodef or target files to a separate script and import the reusable files to other scripts. This helps to separate concerns and make the script easier to maintain.

Use third-party tools to make up for ant's limitations

1. In the absence of exception handling mechanisms, any buildexception will terminate ant execution, and any task may have exceptions, so some cleanup operations will not be executed. solution:

   A. Ant-contrib's <trycatch>

   B. antpublisher. cruisecontrol of cruisecontrol defines the operation after building. For more information, see <cruisecontrol enterprise best practices (1): publish with a publisher>

2. Lack of dependency management mechanism

   As mentioned above, Ivy has become a sub-project of ant.

Other common styles

1. define tasks, datatypes, and properties before targets.

2. order attributes logically and consistently.

3. separate words in Target names with a hyphen .

4. separate words with a dot (.) character in property names .

5. include an "all" target that builds it all.

6. define reusable paths.

7. use explicit classpaths wherever possible.

8. provide visual and XML test results. use , and .

9. used for hyphens (-) the target name at the beginning to define the "internal" target that cannot be called from the command line

Other common skills

1. Interaction with users, which should not be in the continuous integration environment: <input>

2. Concurrent execution: <parallel> is generally used to execute tasks running in the background.

3. Recursive property definition. ant does not support recursive expansion of property by default, for example, $ {$ {OS }. $ {prop }}. however, everything can be solved with an additional middle layer. The borrow mechanism here is <macrodef>

Here is the macro (along lines suggested by Peter Reilly with reference to http://ant.apache.org/faq.html?propertyvalue-as-name-for-property:

 
<! -- Allows you define a new property with a value of $ {$ {A}. $ {B} which can't be done by the property task alone. -->
 

<Macrodef name = "dymanic-property">
<Attribute name = "name"/>
<Attribute name = "prop"/>
<Attribute name = "OS"/>
<Sequential>
<Property name = "@ {name}" value = "$ {@ {OS}. @ {prop}"/>
</Sequential>
</Macrodef>
 

In this way, attributes can be dynamically defined.

<Macro. Compose-property name = "Some. Property" prop = "$ {component} OS =" $ {targetos} "/>

<Do-something-with property = "$ {some. Property}"/>

Weird

2. Spawn, do not use spawn = true, use the previous <parallel>

   By default, spawn is equal to false. In this case, all fork processes are killed when ant exits. setting spawn to true can make the process longer than ant, so as to run the background without blocking ant execution.Program. However, there will be many bad things, such as the inability to view information on the console in real time. in addition, the service life of ant is not expected in some cases. For example, to run ant in the cruisecontrol environment, if the ant fork process does not exit with ant, then cruisecontrol will think that the ant process has not ended, so it will remain there waiting instead of executing the publishers.

   Use <parallel>'s <daemon> to run background programs

4. Wildcards on Unix (no problem on Windows): On Unix-like systems, wildcards are understood by Shell intepreters, not by individual binary executables as/usr/bin/ls or shell scripts.

   <Target name = "list"> <exec executable = "sh"> <Arg value = "-c"/> <Arg value = "ls/path/to/Some/XML /files /*. XML "/> </exec> </Target>

6. How many system attributes are not described in the JDK documentation? -Duser. Country = en-duser. Language = us

Reference

• Http://wiki.apache.org/ant/AntOddities

• Http://wiki.apache.org/ant/TheElementsOfAntStyle

• Ant task notes for programmers