Convert to enhance Ant with XSL
Real examples of features and flexibility about Ant
Jim creasman (create@us.ibm.com) program consultant, IBM 2003 October
Ant is a tool for creating a program to build a script, which is very powerful. After ANT is combined with XSLT, its function and flexibility will be rapidly enhanced. In this article, JIM clarifies this concept with a real example based on his previous experience.
I have led a program to build a group in the past few years. In this time, I witnessed, the software from the concept to the code to the user, has changed a lot of changes. Especially need to point out that tools and techniques for managing construction activities for managing large-scale software development projects have already changed very much.
In the mid-1990s, most source codes were written in c or C . To describe and manage the compilation process of the code, the option to choose is Make, plus the sporadic batch file or the shell script to increase the degree of automation, and your build process is the same.
The era has changed now. There is a Java technology, XML, XSLT, limit programming and continuous construction, and many other new technologies. By the late 1990s, there was a big change. In the program build tool, the biggest change may increase Ant.
ANT is a Java-based programming tool. It comes from the Jakarta project of Apache Software Foundation, has become the fact that the Java project is built. The structure of the Ant script, and a lot of easy-to-use features, are from XML. At the same time, because the ANT script is represented by XML, it can be parsed, modified, generated, or transforms with Extensible Stylesheet Language Transformations, XSLT. You can even call the style sheet for the style sheet inside an Ant task (see a description of the ANT style task).
Two people can jump out of the beautiful tango! Now we have to consider the case where Ant is combined with XSLT. The rest of this article will focus on three instances, each of which elaborates an issue I have encountered in work. In each example, the basic ideas of the solution I have described are combined with one or more XSL style tables. XSLT makes it flexibly originally static scripts. Please consider the use of Ant in these situations according to your experience:
How to simplify the maintenance process of the script How to create a complex script based on XML metadata How to implement a script browser
The value of the problem is reflected in the solution. You may think that every particular example is not used by you, but I believe you can find your own way, using such a simple technology to make your build process vibrant.
Before we start, I want to confirm whether you understand some basic concepts. Each solution I provide requires an XSL conversion. Figure 1 depicts the general way of working with XSLT. In the scenario in this article, Source Document is usually an ANT script, but sometimes it may be another XML data file. Transformation Process Apply the rules in the Stylesheet to the source file and generate the Result Document.
Figure 1. Network of XSLT Process
Example 1: Before using the style build procedure, I worked in a program build group. My team is in contact with many different development organization and supports them to build. I have also supported up to 17 different products and provide nearly 50 release versions for a changing software. Building a script (ANT Target) below shows the general steps that each build process should follow. Each step has realized a default action. By default, most build processes use this default action.
INIT (initialization) start (start)
Setup (setting)
Step.Setup_scm step.setup_base step.setup_delta step.setup_build step.setup_nls step.setup_verify build (Build)
Step.build_release step.build_verify distribute (release)
Step.distribute_connect step.distribute_copy step.distribute_nls step.distribute_verify complete (completed)
Step.complete_scm step.complete_stats step_stats step_Complete_VERIFY
One of the challenges we face is to manage this activity and its diversity. Normally, the development team has little common to the group, and there is no interaction between each other. Therefore, standardization is the key to solving the problem. From the abstract level, our build process is the same at every release:
Define what you plan to build. The source code is extracted onto the computer used to build. Sub-process running compiled and packaged. Release the results of the construction. Notify you of the construction of it.
We originally planned to develop universal scripts, even if it is not all, at least follow all the points. Because there are so many different designs, the problem is also endless. After a while, if these scripts do not look at the tube, they will start to open in different directions. Each script becomes more special. The general maintenance process takes a lot of manpower, time and coordination.
The solution recently, we decided to re-create scripts, to consolidate Ant as the status of the main script tool. We first agree to a default construction process. Since then, we will refine these general tasks listed above, divide a smaller step, each step represents a working unit, and for multiple build processes, Work units may be common. For this refined process, each step is achieved into one or more ANT targets, each with default behavior, adapted to most of the case. In the sidebar "Building Scripts", we give the actual operation order, each step is represented by the ANT target name.
These points are applicable for each build process, but for a particular step, the default behavior may not apply. This is also where XSLT can enhance flexibility. If there is no ability to convert the default script, we may still have multiple copies for almost the same script. It is best to becomes each build process to implement a partial script, which contains the steps only valid for this process. We designed a front-end process (also an ANT script), which runs the style sheet, converts the input document into the build file of Ant. If there is no such steps in this part script, those steps use the default definition.
This process can be represented by the following formula: local target default target style sheet = build script
The local target is included in the main XML file in the input conversion process. The conversion process reads the default target from the secondary input document, merges the result, and specifies the reference to the local script during the merge. Listing 1 shows the
