Software AG Products 10.11 | Administering Integration Server | Managing Packages | Copying Packages from One Server to Another | Specifying File and Version Information for a Release or Archive
 
Specifying File and Version Information for a Release or Archive
When you archive a package or create a release, the server displays a page from which you can specify the files you want to archive or release, the type of archive or release (full or patch), and version information.
Note:
You can also use the watt.server.createPackage.ignorePattern configuration parameter to specify the patterns of file names for the files that you do not want Integration Server to include when publishing packages. For more information about this parameter, see Server Configuration Parameters.
Refer to Archiving a Package for detailed instructions on how to archive a package. Also, refer to Publishing a Package for detailed instructions on how to create and send a release.
*To specify file and version information for a released or archived package
1. Identify the files that you want to include in the release/archive.
If you want to include
Do this
All files
In the Files to include section, select All files.
Most, but not all, of the files
In the Files available in package, section, select the files you do NOT want to include in the archive or release.
In the Files to includesection, select all except selected files.
If the developer added package dependencies or startup, shutdown, or replication services to the package since the last archive or release was created, be sure to include the manifest.v3 file. Otherwise these services will not be available in the resultant package. See Running Services When Packages Are Loaded, Unloaded, or Replicated for more information about startup, shutdown, and replication services.
Only a few of the files
In the Files available in package section, select the files you want to include in the archive or release.
In the Files to include section, select Selected files.
If the developer added package dependencies or startup, shutdown, or replication services to the package since the last archive or release was created, be sure to include the manifest.v3 file. Otherwise these services will not be available in the resultant package. See Running Services When Packages Are Loaded, Unloaded, or Replicated for more information about startup, shutdown, and replication services.
Files with a similar path name
In the Files to include section, select Files specified by filter and enter a valid filter, for example *.java or *.class.
or
To include all files except those with a similar name, in the Files to include section, click All except files specified by filter and enter a valid filter, for example *.bak.
If the developer added package dependencies or startup, shutdown, or replication services to the package since the last archive or release was created, be sure to include the manifest.v3 file. Otherwise these services will not be available in the resultant package. See Running Services When Packages Are Loaded, Unloaded, or Replicated for more information about startup, shutdown, and replication services.
You can specify the following special character to perform pattern matching.
Char
Description
Example
*
Matches any number of characters
*.java
2. In the Files to Delete from Target Packages field, identify the files that you want to delete from the target package. Separate each entry with a semicolon (;). When the subscribing server installs the package, the server deletes these files from the target package.
3. Specify package version information and description:
Field
Description
Archive/Release Type
Full: All files in the package are written to the archive or release
Patch: Selected files in the package are written to the archive or release. When the administrator on the target server installs a patch archive or release, the files contained in the patch archive or release replace the versions of those files in the target package; all other files in the target package remain intact.
If the developer added package dependencies or startup, shutdown, or replication services to the package since the last archive or release was created, be sure to include the manifest.v3 file. Otherwise these services will not be available in the resultant package. See Running Services When Packages Are Loaded, Unloaded, or Replicated for more information about startup, shutdown, and replication services.
Archive/Release Name
A name you assign to the archive or release, for example Beta Release of WmExample Package.
Brief Description
A description you assign to the archive or release, for example “Dec release with patches to correct OrderProcess problem.”
Version
The version number you assign to the package you are archiving or releasing. This version might not be the same as the version of the package itself. When a developer first creates a package, the version number is set to 1.0.
For more information about the checking the Integration Server performs, see Version Checking.
Build Number
A number that a developer assigns to a package each time it is regenerated. For example, a developer might generate version 1.0 of the WmExample package 10 times, assigning build number 1,2,3...10.
Patches Included
A list of patches that have been applied to this release of the package. These are numbers that are meaningful to your installation, possibly obtained from your problem tracking system.
4. Specify subscriber settings:
Field
What It Means
webMethods Integration Server
Version of the webMethods server that must be running on the target server.
For more information about the version checking performed by the subscribing server, see Version Checking.
Minimum Version of JVM
Minimum version of the Java Virtual Machine (JVM) that the target Integration Server should be running when using this package. When the administrator installs the package, the server checks the version of the JVM it is running. If it is running a lower major version of the JVM, the server installs the package but does not activate it.
For more information about the version checking performed by the subscribing server, see Version Checking.
5. Specify version of target package (for patch releases only).
6. This is the version of the package the target server must be running. When the administrator installs the patch on the target server, the server checks to make sure the version of the target package is the same as the one specified here. If the target package is a different version, the server does not install the package. This restriction gives you greater control over how and where patches are applied. This is useful because patches are typically release dependent.