This is the first translation article, and the level is limited, and there is nothing to include. Welcome everyone's criticism and finger. In addition, only part of the original content is translated, please understand.
Ant in anger (ANT IN AGER)
Using Apache Ant in project development
Steve Loughran
Introduction
Apache Ant can become a valuable tool for team project development, and it may also become another trouble of project development that has encountered crisis projects. This document contains some measures and strategies capable of playing ANT power. Some parts have been properly simplified, and examples of all Ant XML files are almost omitted.
Core practice
Clarify you want Ant what to do
Ant is not a silver bomb, it is just a rusty bullet in the software development tool of the software developing tools. Its initial purpose is to accelerate the construction and release of the Java project. You can of course expand Ant to do anything to make anything that makes it possible: For example, it is easy to imagine to write an image processing task to help URLs to compress and extract the JPEG image file. But this also makes the real purpose of Ant become blurred, so please consider it carefully.
Ant is also an important supplement to integrated development environments. One thing that does not have a wonderful release management and a construction method of clean, automated. But a good modern integrated development environment is a productivity tool in its field, a tool you can consider using it. Ant just allows you to give your team to develop more free - "You can use any tool development, but use Ant to build." Now there are many modern open source and business integration development environments including ANT support. Developers can use a powerful development environment and then use integrated Ant to provide a strict lightweight construction process.
Define standard objectives
When you have multiple sub-projects, define a standard goal. Engineering of JAR files with interfaces and implementations can consider IMPL and intF targets - use separate debug-impl and debug-intf targets for this debug version. Of course, there is a Clean target that needs to be everywhere.
Using standard target names, it is easy to build an Ant build file containing it, which uses Ant tasks to build engineering into class files. For example, the Clean target can pass the INTF and IMPL subdirectories from the parent directory.
If you give a target to describe the tag, then running Ant -ProjectHelp will list all the tasks with the 'main target' descriptor, and the task of no sub-target descriptor. Give you all the entry points to describe tags, especially before projects become huge and complicated.
Expand Ant through new task
If Ant can't do what you want, you can use Exec and Java tasks or inline scripting to expand it. In an engineering with a large build.xml file, you will soon find that it will reduce the maintenance cost in a single main place. Using Java code to implement task extension seems to add additional burden, but there is an additional benefit:
l Don't change any build.xml files, you can then implement cross-platform support.
l The code can be submitted by the ANT project itself for others to use and maintain L this makes the build file easier.
To some extent, a declap from the use of the "Build File" - "Task", helps Ant success. If you have some complicated things in Make or IDE, you need a lot of Makefile files that everyone fear, or IDE configuration files, and these files are always very fragile. But Ant tasks are all Ant users to be reused and shared. Many current ANT cores and optional tasks, and you can do now and upcoming tasks, you can use those who write when solving their own problems.
Embrace automation test
Ant allows you to evoke the JUnit task so you can test your team's code. Automation test seems to be an additional burden, but JUnit makes the unit test very simple, you have no reason not to do. Take some time to learn how to use JUnit, write test cases, and integrate test goals to Ant, so your daily or time build can apply automation tests.
If you want to add a way to get the code from the supply chain system, you or through some shell scripts or batch files as an Ant task, or through some continuous integration tools. The integrated test code can be a pure Ant task that can run in any test box belonging to this task. This verification construction and unit testing can be ideal for work from a general developer's machine to different goals. For example, in the Win95 / Java1.1 environment, it can also be used, although there is no developer to use this configuration without developers.
Automated system test is difficult than the unit test, but if you can write Java code to strengthen most of your system - even if these code cannot run like a JUnit task - such a Java task can be used to call them. You'd better indicate that you want to use a new Java virtual machine to test, such a major destruction will not destroy all build. JUnit expansion, like httpunit to test the web page, CACTUS test J2EE and Servlet to help extend the test framework. For the right test, you also need to pay a lot of effort to work together with your project, and test from big units, systems and recession - but your customers will like you because you make the software like you. .
Society to use and like Ant addresses
The distribution version of Ant is not the limit of the Ant world, which is just the beginning. Look at the Extended Tools and Task Page as an extension list, here is some of them.
l Checkstyle
This tool reviews your code and generates an HTML report that is destroyed by any style. Nothing can hide this code police! Tip: The sooner it starts, the less your corrections.
l Ant-contrib
This SourceFourge project includes help tasks that can be separated from the ideology of the ideology from the core Ant; especially the Foreach and Trycatch tasks. This can give you repeated and extra error handling. Moreover, there is a
l xdoclet
XDoclet adds Java to planned properties. By adding a Javadoc tag in your code, you can automatically generate web.xml description files, taglib descriptors, ejb interfaces, JMX interface classes, XML / SQL bindings, and more. The key here is that all highly accurate small XML files You need to create, EJBs and JMX interfaces You need to implement, can be generated by adding some help attributes in the Java code. This reduces the mistake, meaning that you can change your code, let the other parts of the application get a prompt from the source code. Without it, don't make EJB, JMX, and web applications! ANT cross-platform
ANT is the best foundation for cross-platform Java development and testing so far. But if you are not very paying attention, it is likely that you can only build a platform in one platform - or even a workstation.
The main obstacle to cross-platform Ant use is that the use of the command line tool (Exec task) is not portable, the path is related, and it is difficult to decode the location of the event.
Command line application: EXEC / APPLY
Trouble with external call is not all functions can cross the platform, and they have different names - DOS systems always expect .ext and .bat as the file end. If you are clear in the command name, it will be very bad, but when it allows the same binary directory in the project that is not in the name of the project, it is very wonderful. .
These two command line call tasks require you to indicate that you want your code to run in the platform, so you can write different tasks for each platform you intend to use. Alternatively, the difference in the platform can be solved in the expansion code of Ant call. This is some Java files compiled in new tasks or peripheral scripts files.
Path cross-platform
The UNIX path uses a front slash (/) divided directory, colon segmentation entries. This "/bin/java/lib/xerces.jar:/bin/java/lib/ant.jar" is the path in UNIX. The path must be used in the Windows path to indicate the colon of the drive, and after the slash (/). For example, "c: /bin/java/lib/xerces.jar; c: /bin/java/lib/ant.jar".
The difference between this platform has caused a lot of trouble.
ANT reduces the problem of this path, but there is no effort to eliminate them. You also need to do some work. Solving the rules of the path name is to solve the path name of the DOS system and the path name of the UNIX system. Disk Name "C:" can be solved in the DOS system, but put them in build.xml to make all portable bankruptcy. The related file path is more portable. Sequel as an entry split - If your Ant call includes a series of JAR files defined in the command line, the semicolon is very useful. In the build file, you'd better build a classpath, list separate files (using location = attributes), or include a * .jar fileset in the ClassPath definition.
The PathConvert task can convert all related paths to an attribute. Why do you want to do this? Because you can use the path in other ways -, for example, pass it as a parameter to the application you call, or use the replacement task to patch it into a locallyified shell script or batch file.
Note that the DOS-based file system is case sensitive, and the suffix of 4 or more characters on the surface of the Windows surface is actually 3 characters (Try using delete * .jav in your Java directory. You can see catastrophic consequences).
Ant's strategy is sensitive, regardless of that file system, which is not looking for any .java files when searching * .jav files on the processing of the suffix name. The Java compiler is of course sensitive - you cannot implement 'Examplethree' classes in "Examplethree.java". Some tasks will only be performed on a platform --chmod is a typical example. These tasks often lead to only warnings - other targets of the objects are still called. Other tasks degraded their features on the platform or Java version. In particular, those who adjust file time printed will not work properly under Java1.1. For example, Get, Touch, and Unjar / Unwar / Unzip tasks can be done, in Java1.1, regularly, often, can only be used for current time printing.
Finally, Perl does not need a series of files to make Java call cross-platform work. Most UNIX distribution packs contain Perl, and it is easy to download from ActiveState to its Win32 version. With the PERL file with the .pl extension, the first line with a general Unix path, is marked as available, can run on Windows, OS / 2, and UNIX, which can be called from Ant without modification . Perl code can also be used to solve its own cross-platform problem. Don't forget that when you re-release the Perl code, set the end symbol to accommodate the platform.
