During the development phase, the release requirements of the program may be different in different user environments, such as the setting of configuration parameters, the system installation path, the path to the third party library (if not intended to join the third party library to the released zip package) . We can solve this problem with custom Properties while writing Build files, will be abstracted to Properties, you can also put these Properties separately in an external file. When multiplayer is developed, if you join these volatile Properties, you must change again from the CVS downloader from the CVS to the local, and this change may have to be updated with the corresponding file in CVS. BUILD files, or a separate Properties file), this is obviously inappropriate.
To do this, we can use the User.home path on each local machine to put the Properties file there. This file does not have to be placed in CVS, and the ANT automatically goes to find the file and load it when it is backed. As for the User.home path, Linux is / home /
Usually C: Document and Settings under Windows
. among them
For the current username. You can also use system environment variables in Ant.
Setting, so more flexible. The environment variable under WindWOS is HomePath, and Linux is Home.
The previously mentioned Properties file is simply used for the Build process, and we can also do a similar flexibility improvement for the Properties file included in the final release system. First, write a Properties TMPLATE file to CVS, first in the Build file, first, first, set the TMPLATE file COPY to "instance" file, then replace some configurable items. We can put the replacement values of these configurable items in another Properties file, and the file is not placed in CVS and put it in the User.home path. String replacement can be used
or
.
Of course, when publishing a complete installation package, it may also also need to "join" to the PROerties file of the local machine to the installation package. One way is to write an exemplary template file, add it to CVS, and the development phase does not use the file. When you generate the installation package, the template file is also entered in the package, and the instructions are added to the installation document published with the product. In this way, the user can follow the instructions, manually COPY a "instance" file, and then do some targeted configurations. The deficiency of this method is that the user is required to do additional work. If the installation package has a good characteristics, then the user may only need to simply run run.bat (for running versions), or build.bat (even It is also a build process that can be running versions, just like AnthillPro. To do this, we need to generate a "final release" file in the target of the Target that completes the release task, so that this file is only used to get into the package.
Change frequent Properties should be independent of Build.xml, separately as an external Properties file. In particular, the user-related Properties is the so-called User-Specific Properties. Such files are not placed in the SCM, but put them in the user.home of the local machine.
Long-term unchanging Properties can usually be placed in the first part of the build.xml file. These Properties also have the necessary, occasional adjustments in the development phase, their role is like the constant definition in programming - change in the change, all over the whole - convenient and easy to maintain. Of course, these Properties should be saved in the SCM with the build.xml file. More complex means is:
Provides Project-Specific's Properties file in addition to some global configurations of the project in addition to the User-Specific configuration. The variability of these configuration items is often lower than the USER-SPECific configuration item, but the long-term development cycle is still possible, and such a Properties file should be placed in the SCM. One of the most obvious examples is Project.Version, one of the purposes of this configuration is part of the path or file name when generating the published software, just like Tomcat's HOME path is usually Jakarta-Tomcat-
.
The user-specificia configuration item and the Project-Specific configuration item allow interoperability. When both conflicts, User-Specific can override Project-Specific, which is higher than the priority. Depending on the Immutable Properties principle, this means that the build.xml file should first load User-Specific Properties.
According to the actual situation, there may be a class of most variable configuration items. That is the Properties that may vary during each build process, called Build-Specific Properties. At this point, we can configure the command line parameter -d of ANT. Priority of such configuration items is the highest by the characteristics of Ant. Of course, in general, this configuration item is still less.
Plus the previously mentioned Properties in the build.xml file, I will temporarily name it as Inner Properties, the variability and priority of all kinds of ProEprties are as follows:
Category Volatility Priority is located in the build-specific property in the high high NOUSER-SPECIFIC PROPERTIES high NOPROJECT-Specific Properties low low YESINNNER Properties low YES
In summary, four different levels of Properties, sufficient to cope with most projects.
