Extra Targets

A number of extra Ant targets are provided which are not necessary to build a server. Some of the more useful targets are listed below:

clean - Delete all the generated and compiled files to ensure all generated and compiled artefacts are removed and the next build is fresh and clean. It is useful to periodically perform clean builds because of limitations in the dependency checker provided by Ant.
encrypt - Encrypt a plain-text password (e.g. for curam.db.password) so the encrypted password can be safely stored in a property file. None of the Cúram property files contain plain-text passwords so the passwords contained within them are automatically decrypted. See the Cúram Security Handbook for more information regarding cryptographic settings for encrypted passwords.
digest - Digest a plain-text user password. When you change cryptographic digest settings, for internal and external Cúram users, you may need to update digested password values in DMX (e.g. USERS.DMX) and SQL files for passwords to be stored on the database. To make these updates you will need the new digest password values, which you can obtain via this target. Care should be used in creating these passwords and should only be done for test users. See the Cúram Security Handbook for more information regarding cryptographic settings for digested passwords.
database - This transforms the database independent xml files into DDL files and places the contents of these DDL files on the database. The database target also provides support for applying rule sets to the database (more detail on this is provided in Rules Targets).
mergeshortnames - Merges file ShortNames.properties from all components
extractdata - This extracts the contents of all or some of the tables on the database and transforms them into database independent XML files. More detail on this target is provided in Data Manager.
reloadextracteddata - This reloads data that was extracted using the extractdata command back onto the database.
checksql - This validates the hand-crafted SQL and test data against the actual database. If this step is not run syntactical (and semantic) mistakes in hand-crafted SQL will not be determined until run-time because of the dynamic nature of JDBC (Java Database Connectivity)¹. This step operates by producing an SQLJ file and completely relies on the syntax checking provided by the particular database. The checksql target uses the output that is built during the database target. So it is a pre-requisite to have run database target before running checksql. Any errors that are discovered while running the checksql target are logged to the console and to a timestamped log file in the buildlogs directory. More detail on this target is provided in SQL Checker.
deprecationreport - The command-line Java compiler deprecation warnings have been extended to apply to certain Cúram builds and validations. This helps to quickly pinpoint where custom dependencies exist on deprecated out-of-the-box artefacts. This target combines all the Cúram builds and validations that support deprecation warnings. As such, the build output from this target provides a comprehensive overview of all deprecation warnings for all supported builds (server and client builds, workflow validations, rules validations, etc). Please note that this target starts with a clean (as the Java compiler does not produce warnings for incremental builds). See Deprecation for more information.
foreignkeycheck - In a production environment it is not desirable to enable foreign keys on the database because of the result performance degradation. As a result it is possible for referential integrity to be violated as a result of program bugs or manual intervention by a Database Administrator. This target validates that the Referential Integrity has not been violated. It performs this task by loading the generated foreign key constraints for the application and verifying that for each child record of each foreign key the referenced parent key exists. The key values of any missing parent key records are reported.
test - Execute the tests associated with the application.
- If Clover is available a code coverage report can also be generated. More details on the usage of Clover are available in Clover Targets.
- The JUnit forkmode controls the number of Java Virtual Machines that gets created if you want to fork some tests; and it can be set dynamically by specifying junit.fork.mode property, while executing the test target.
  For Example:
```
build test -Djunit.fork.mode=once
```
  Possible values for this property are:
  
  perTest - creates only a single Jav Java VM for all tests.
  
  perBatch - creates a Java VM for each nested batch test and one collecting all nested tests.
  
  once - creates only a single Java VM for all tests.
  
  Default value of perTest is used if junit.fork.mode property is not set.
- It is possible to exclude or include set of tests while running the test target. To Exclude/Include tests, copy the ExcludeTests.txt or IncludeTests.txt file located in the CuramSDEJ\util\ directory. This new file can then be modified to add the tests that you want to exclude or include and can be reference using the property override.
  For Example:
```
build test
    -Dexclude.test.file=<PATH_TO_THE_FILE>\ExcludeTests.txt
build test
    -Dinclude.test.file=<PATH_TO_THE_FILE>\IncludeTests.txt
```
configtest - Examine the current environment to ensure that the various environment settings and property files have been established correctly. This tool attempts to diagnose any problems in the environment which would be an impact. It checks the validity of the:
- versions of third party tools including Java SE Runtime Environment (JRE), Ant, application server and database.
- Bootstrap.properties including properties curam.db.name or curam.db.oracle.servicename, curam.environment.bindings.location, curam.db.username, curam.db.password and curam.db.type
- database connectivity by attempting to connect to the database described by properties in Bootstrap.properties and ensures it is a valid database.
- database configuration e.g. DB2 buffer pools and tablespaces, Oracle privileges for the Cúram user
- application server variables: WAS_HOME and WLS_HOME dependencies are also checked i.e. if using WebSphere the IBM® JDK and IBM Java EE must be used.
- Ant variables i.e. ANT_HOME and ANT_OPTS
- server and client environment variables
configreport - Create a config_report.zip file containing all the relevant settings and software versions on the machine. This can be used if remote support is required.
javadoc - Produce the Java Documentation (JavaDoc) from the application. To produce useful JavaDoc, comments must have been placed in the model as well as in the code.
apijavadoc - Generates the javadoc for black/grey box components, this is based on the javadoc.properties files.
release - Gathers all the files together that are necessary to run Cúram on another machine in the <SERVER_DIR>/release directory. This target is used when building for a target platform (e.g. building on Windows for deployment on IBM z/OS® ) or moving the application between machines. On moving the release directory to another machine a Bootstrap.properties and AppServer.properties property files must be placed in a release/project/properties directory and the following environment variables must be set: SERVER_DIR must point at the release directory, SERVER_MODEL_NAME must be set to the name of the application model, and CURAMSDEJ must be set to the location of the SDEJ before any of the scripts can be used. The SERVER_COMPONENT_ORDER environment variable must be set on your target environment where you plan to work with the resulting release directory, and this value must be the same as the value used in your source environment. The files that are copied are:
- Ant Build files;
- Project jars;
- DDL files;
- SQL files;
- Code Tables files;
- Batch Launcher;
- Data Manager;
- Application EAR files.
- XML Server files.
insertproperties - Merges all the properties (.prx) files defined under the properties directory for each of the application's components, and inserts them into the database. See Application Properties for more details.
extractproperties - Extracts the properties from the database, and stores them into a database independent prx file. The generated prx file is stored at <SERVER_DIR>/build/propertiesextractor/
mergeuserpreferenceproperties - Merge the user preference properties files.
model - Extract the model and generate source code and other artefacts from the XML representation of a Cúram application. The model target combines the modelext and modelgen targets.
runbatch - Runs the Batch Launcher. For more information refer to the Cúram Batch Processing Guide.
runstatistics - Runs statistics for the database. For more information refer to Statistics.
supplement - Compiles and jars all the Java files contained within any supplementary directory specified by the -Dsupplement=<DIRECTORY_NAME> parameter. A <DIRECTORY_NAME>.jar file will be created and stored in the <SERVER_DIR>/build/jar/ directory.
police.access.restrictions - Provides a report of accesses to restricted APIs within the Cúram application. The APIs that are restricted are marked by annotations within the Javadoc and indicate areas that should not be accessed by custom code. This policing tool highlights any code that accesses restricted APIs and out-of-the-box code containing a restricted annotation. During development these restrictions are further backed by the non-delivery of sample Java files, Eclipse access restrictions and that there is no JavaDoc available.

¹ JDBC (Java Database Connectivity) is part of the Java Development Kit which defines an application programming interface for Java for standard SQL access to databases from Java programs.