Build Files

Buildfile Output

A critical part of the ITAG Release Process integration is properly packaging deployable components so that the ITAG deploy scripts know how to process them.  Below is a list of the currently recognized deployable component types and how they need to be packaged for proper integration.

itag-webapp

This is the normal webapp WAR file that must be further wrapped inside a JAR file.  The name of the outer JAR file should match the name of the inner WAR file except its

File name:
Prefix is webapp name, extension must be “.itag-webapp”.

Deployment directory:
/opt2/tomcat/tomcat6-[container-port]/webapps

Example:
If a webapp is normally packaged as a WAR file called ‘epet.war’, in order for the ITAG build scripts to know how to process this, I would have to further package ‘epet.war’ inside a JAR file called ‘epet.itag-webapp’.  I end up with a file named ‘epet.itag-webapp’ that is actually a JAR that only contains one file, ‘epet.war’.


itag-jlservices

This is the normal WAR file packaging for jlink services that is further wrapped inside a JAR file.  (see Appendix A for a footnote)

File name:
Prefix should match inner WAR name, extension must be “.itag-jlservices”Deployment directory:  /opt2/tomcat/tomcat6-[container-port]/webapps

Example: 
If jlink services are normally packaged inside a WAR file called ‘ws_student.war’, in order for the ITAG build scripts to know how to process this, the WAR file would have to be further package inside a JAR file called ‘ws_student.itag-jlservices’. The end result, ‘ws_student.itag-jlservices’, is actually a JAR file that only contains one file, ‘ws_student.war’.


itag-perl

These are perl scripts packaged inside a JAR file.   The JAR file’s internal file must match the file structure required to run the scripts on the server.  What’s happening underneath is the ITAG deploy process will explode the JAR file on the server exactly as its packaged.  This means if the JAR file structure doesn’t match the server file structure exactly, then the deploy will fail.

File name:
Prefix with project name, extension must be “.itag-perl”.

Deployment directory:
/opt2/actj2/secured/cgi-bin This is a shared server directory so it is critical JAR packaging is made relative to this directory.

Example:
A project named “tritonlinkperl” may produce a component called “tritonlinkperl-perl.itag-perl”. itag-web             These are web-related files like html, css, js, php, and image files that are centrally located for other apps to use.  Most often they are consumed by perl apps or are mobile apps.  They should be packaged as a JAR with the appropriate runtime structure and anFile name:  Prefix with project name, extension must be “.itag-web”.

Deployment directory:
/var/www/html This is a shared server directory so it is critical JAR packaging is made relative to this directory.


itag-files

These are files, usually xml descriptors, consumed by other applications.  They should be packaged as a JAR with the required runtime structure.  There are several name spacing conventions in place for files deployed here.  If your project needs to deploy a module here you must find out ahead of time which naming conventions you need to enforce.  For more information see [TBD].

File name:
Prefix with project name, extension must be “.itag-files”.  Deployment directory:  /opt2/filerepository This is a shared server directory so it is critical JAR packaging is made relative to this directory.

Example:
The project “apol” produces several itag-files deployable components:

  • apol-bpel.itag-files
  • apol-bpel4ws.itag-files
  • apol-rest.itag-files
  • apol-soap.itag-files itag-batch

itag-batch

These are the normal batch jobs packaged as JARs.   The structure of the JAR must adhere to the required ACT structure as set forth by Production Control.  The name of the JAR should be prefixed with the name of the project to ensure proper name spacing.

File name:
Prefix with project name, extension must be “.itag-batch”.

Deployment directory:
/dw/apps/SCSC and /dw/apps/NON_SCSC_scripts These are shared directories so it is critical that JAR packaging is made relative to this directory. itag-platform-webapp These are webapps that help form the runtime platform for other apps.  Jlink webapps and the ‘decorator’ webapp are examples.  Since they are part of the platform they must be processed with extra care.  This extra processing and required packaging has yet to be finalized. [TBD]

File name:
Prefix is webapp name, extension must be “.itag-platform-webapp”.

Deployment directory:
/opt2/tomcat/tomcat6-[container-port]/webapps


itag-platform-lib

These are any JARs that reside on the server classpath.  As such, they contribute to the platform for all other apps.  Since they are part of the platform they must be processed with extra care.  This extra processing and required packaging has yet to be finalized. [TBD]

File name:
Prefix should match JAR file name, extension must be “.itag-platform-lib

Deployment directory:
/opt2/tomcat/tomcat6-8083/lib

Example:
jlink2.itag-platform-lib would be a JAR that contains jlink2.jar

Leveraging existing build files

Many projects have already incorporated Ant build files into them.  When creating new integration build files a group may decide to use targets from their existing build file rather than copying them.  This can be done using the <antcall> feature of Ant.

<!-- call existing build target -->
<antcall target="target-from-existing-buildfile"/

If this approach is used, the target in the original build file must also be able to run without any environmental dependencies.  This is likely to require modifications of the existing build file.  While this approach is possible, it is certainly not required, and groups may find it’s easier and faster to just copy old targets into the new integration file and make modifications there.

Testing your integration build files

The ITAG release script includes a flag for performing a test run [TBD].

See Appendix B

for an example of testing your itag-build.xml script on your desktop.