Introduction
When you have configured a Version and packaged some source code successfully but your packages contain warnings, errors or alerts, you must ensure that these warnings/errors will not impact the analysis and that any alerts are dealt with correctly. This will involve fine tuning your Version and Packages, remediating/ignoring alerts and then re-running the packaging action. This is explained below.
Validate at Package level
Validate package content
The first thing you should do is to check the Package Content tab for each Package in your Version. This tab displays information about what the CAST Delivery Manager Tool has discovered in the source code package according to the selected discovered and other configuration settings set in the Package Configuration tab:
Click to enlarge
Check the following:
Projects found
That at least one Project has been identified and selected in the Projects found section - projects that are marked with Selected will be automatically transformed into Analysis Units when the Version is accepted in the CAST Management Studio. Note that it is entirely possible for no projects to have been identified and selected in the in the Projects found section - this can occur when packaging a supported technology for which no "discoverer" exists (for example when using the SQL Analyzer extension to package DDL). In this case it is safe to continue - you just need to ensure that you create the required Analysis Units in the CAST Management Studio.
Project type | This indicates what project type the CAST Delivery Manager Tool has assigned to the projects identified in the source code package. |
---|---|
Technology | Indicates what technology type the CAST Delivery Manager Tool has assigned to the project. |
#Selected | Indicates the total number of projects identified by the CAST Delivery Manager Tool in the most recent Source Package and which will be packaged for Delivery. Projects that are marked as Selected will be transformed into Analysis Units in the CAST Management Studio. If no projects are marked as Selected, then no Analysis Units will be created: you may need to review your package configuration. |
#Ignored | Indicates the total number of projects that have been ignored. A project can be ignored in various ways:
Information about excluded/ignored items and how they are handled in the CAST Management Studio When a project is marked as ignored after an initial run of the Package action, the following rules determine how the corresponding project is handled in the CAST Management Studio when the Set as current version option is actioned.
This has the following impact:
There are some limitations to these rules:
|
#Added | This column displays the number of projects that are "new" in the current Source Package in comparison to a Source Package in an older Version. |
#Removed | This column displays the number of projects that are no longer present in the current Source Package in comparison to a Source Package in an older Version. |
Define exclusions if necessary
You may now need to exclude some projects that have been discovered and marked as Selected during the initial Package action so that they are not included in the delivery. For example, you may not want to deliver projects that are not directly used by the projects you need to deliver. The information gathered during the Application Architecture Review (see Qualification) will help guide the validation of the application boundary and decide what should be excluded from the internal objects and link representation of the analyzed application.
Files found
The Files found (only when working with file based source code as oppose to a database or schema) - ensure that the file extensions listed and the number of files are as expected.
Log Summary
The errors or warnings in the Log Summary section, for example in the image below, a warning is present in this package - click the log button to view the log file and identify what the issue is:
Click to enlarge
Manage packaging alerts
Alerts generally indicate that the source code package is incomplete, that there is a configuration issue or simply that there is something wrong in the source code. If these alerts are not dealt with and the Version is delivered, then there is a risk that the source code analysis executed in the CAST Management Studio will be erroneous or may not even complete.
Package Alert tab
Any alerts are shown in the Package Alert tab:
Click to enlarge
This section displays a list of any "alerts" that were raised during the Package action. Alerts can come in various different types (non-exhaustive list):
Undefined variable | A variable has been discovered in the source code in the source package. The CAST Delivery Manager Tool cannot detect a value for this variable and therefore an alert has been created. |
---|---|
Missing project | A reference to a project, library file, folder or resource has been discovered in the source code package. The CAST Delivery Manager Tool cannot detect this specific item anywhere in the source code package and therefore an alert has been created. When packaging Eclipse based Java code in the CAST Delivery Manager Tool, you may receive Missing source folder alerts even though the source folder that is recorded as being missing is actually present in the source code. This alert is usually generated when no .project file has been found in the folder that is recorded as being missing. To resolve this alert, you can manually add the missing .project file and then re-run the packaging action. |
Missing library file | |
Missing source folder | |
Missing resource |
Selecting an alert type will show the list of specific alerts that have been raised for that type:
Alert | Indicates the item that has caused the alert - a reference to an item in the source code package that cannot be detected, or a variable that is undefined. Note that a source code "version number" will be added to the Alert column when a Technology that uses source code versioning has been packaged, see the example below: |
---|---|
Project name | Indicates the name of the project derived from the project's configuration files. |
Project path | Indicates where the project is located in the Source Code Package - this refers to a folder (for file based source code packages) and to a database (for databases based source code packages). If a dot "." is displayed, this indicates that the project is located at the root of the source package. |
It is up to you as the Delivery Manager to manage these alerts. Initially, you should always attempt to remediate alerts using the following methods:
- by altering the source code package configuration (for example the root path defined in Package Configuration tab - Where is your source code? may be incorrect) and then re-running the Package action
- by creating additional source code packages that target the missing projects, files and folders and then re-running the Package action
- by altering your original source code and then re-running the Package action
If you still have alerts after performing the above actions, you may need to use an ignore action or remediate them manually as discussed below.
Ignoring alerts
If you know that an alert is false or will not impact the source code analysis, then it is possible to ignore the alert. This action is, however, generally used when re-delivering a new Version of your source code: by ignoring alerts from the current Version, you can easily identify new alerts in the new Version.
Using manual remediation items
If you know that an alert can be resolved because a missing item is located in another source code package, you can create a manual remediation item that will "tell" the CAST Delivery Manager where the missing items are located. In the same way, missing variables can be manually remediated by defining the variable that is required.
When you next run the Package action, the CAST Delivery Manager Tool will use the remediation item to fix the alert. The alert will then be cleared.
Re-run the Package action
To ensure that the exclusions/alert remediations you have defined are taken into account, you need to re-run the packaging action at Version level (i.e. all packages are re-packaged):