In order to create a centralized script capable of building and deploying all existing ITAG projects, projects first had to be categorized. More specifically, each type of deployable component had to be identified and categorized. The underlying concept is that projects are composed of one or more deployable components. The ITAG scripts have been designed to support these projects by categorizing deployable components into ‘types’ and then defining a deployment package for each ‘type’. A ‘deployment package’ is simply an archive file (war, jar, zip, tar, etc.) that follows a specified internal file structure (A webapp packaged as a WAR file is an example of this).
Although all components are deployed to the servers inside archive files, the ITAG scripts are designed to know which components should be extracted from their archive file and which should remain packaged. This archive file packaging helps facilitate building, deploying, and versioning in a uniform way. Each specific ‘type’ of deployable component maps to a specific root deployment directory on the server. This just means all modules of the same type share the same (top-level) deployment directory on the server. (e.g. all webapps are deployed to the same directory, all perl apps are deployed somewhere underneath the same top-level ‘cgi-bin’ directory, etc.) A module type is a brief label intended to be descriptive of what is contained inside the archive. Currently ITAG recognizes 8 different ‘module types’. Some of these modules have their archive file structure defined for them by Java/JEE, for the others ITAG has had to define the archive file structure. Each ITAG project should contain one or more of these deploy types. As new deploy types come about, this list will grow to encompass them. No project should have a deploy module that is not covered by one of these.
webapp packaged inside standard WAR file
jlink services packaged as WAR (see Appendix A for a footnote)
batch file apps, packaged inside JAR, package structure must use existing ACT structure
perl scripts, packaged inside JAR, package structure must match runtime structure
web-related files(html, css, js, php, images, etc.), often used by other apps such as perl, package structure must match runtime structure
support files consumed by other applications, (e.g. ReST, WS & BPEL descriptors, qlink models), previously deployed inside of other webapps now deployed into file repository, package structure must match runtime structureitag-platform-webapp platform webapp packaged in standard WAR format, a platform webapp is a webapp that has the potential to affect every application, typically these are jlink webapps and the decorator
platform library packaged in standard JAR format, a platform library is a JAR file that lives on the server classpath (i.e. a JAR that has the potential to affect every application)
Similar to itag-files except this package deploys content files for cognos to the /opt/ibm/cognos_10.1.1/c10_64/webcontent
The phrase ‘package structure must match runtime structure’ is intended to convey the notion that the file structure inside the archive file (jar, tar, zip) should be identical(relative to a specific root directory) to the file structure used by the server at runtime. The idea behind this is to allow the deploy script to simply explode the archive file without having to further manipulate the files.