Distribution Contents Validation Tests

The main purpose of the DistributionValidationTest.java class is to validate the contents inside a product distribution. This page will illustrate the main aspects of the distribution validation test class and some related information.

Objective

There are seven major distribution validation aspects being covered via the DistributionValidationTest.java class. These are as follows:

1. Validation of .jar files inside the product distribution against the LICENSE.txt.
2. Recursive scan to find the occurrence of SNAPSHOT keyword in file names and contents of textual files (E.g. .txt, .xsd, etc).
3. Validate duplicate .jar entries inside the LICENSE.txt file.
4. Check whether maven variables are properly replaced inside configuration files found in the  repository/conf directory.
5. Validate product distribution size against the latest released distribution in the maven repo.
6. Identification of duplicate jars inside the distribution pack.
7. Product specific checks - validate sample directory - versions, resources validation.

There are several distinct test cases being developed to cover the above major aspects and based on the findings/outputs under each category a summarized report will be generated with all the information included. You can navigate to /target/DistributionValidationTestReport.txt to find the report.

Prerequisites

• XSD (XML Schema Definition) files for configuration files (E.g.: carbon.xml, axis2.xml) inside the repository/conf directory. You can generate these schemas using on-line XSD generators.

• Latest released version of the product distribution being hosted in maven-repo.

Description

1. Validation of jar files inside the product distribution against the LICENSE.txt
   
   The implemented test case is capable of identifying the .jar files which resides inside the xxx/repository/components/plugins directory against the .jar file names mentioned in the carbon_home/LICENSE.txt file. Firstly it will derive all .jar file locations inside the plugins directory and match these against the LICENSE.txt file to identify the missing jars.  
2. Recursive scan for occurrence of SNAPSHOT keyword in file names and contents in textual files (.txt, .xml, etc).
   
   The test will perform a recursive scan in order to identify occurrences of the keyword “SNAPSHOT” inside the textual files and in their names. If an occurrence(s) is found, the test will encounter a failure at the relevant assert statement.
3. Validate duplicate entries in the LICENSE.txt file.
   
   Test case will search for duplicate .jar file names (if the same name is appearing more than once) in the LICENSE.txt file. These file names will be stored using a collection interface and finally the test case will output these .jar file names to the report.
4. Checking whether Maven variables are properly replaced inside the configuration files found inside the repository/conf directory.
   
   The test case will check for maven variable replacements by performing xml schema validation techniques. The user of the test case needs to provide the xsd (XML Schema Definition) and files of the corresponding xml’s need to be checked. Mainly the test case will focus on the  '$' signs (these are the tags expected to update at the build time) in the XSD files and validate the relevant XML file for updating of each tag attribute value.

5. Validate product distribution size against the latest released distribution in the maven repo.
   
   The intention of this test case is to validate the running distribution size against the latest released distribution pack size. The test case will access the relevant maven repo and seek for the latest distribution hosted in it. Next, it will retrieve the size of the distribution hosted and evaluate it with the running distribution size.

   You need to make sure that once a release is done, the distribution pack should be hosted in the repo. Size comparison will be based on the pre-accepted value range for all WSO2 products.

6. Identification of duplicate jars inside the distribution pack.
   
   Test case is designed using special regular expressions to derive the version of every .jar file and identification of duplicate .jars inside the pack. Based on the findings of the test case, .jar file locations will be printed in the report file under two categories, duplicate jar files in the same directory and with different versions inside the distribution.
7. Product specific checks for whether samples/resources are properly packaged.
   
   For this purpose the test case will perform some specific scans inside each sample directory and verification will be carried out to confirm that the top most level sample directories do not carry any versions with their names. In addition, the test case is capable of identifying whether the samples directory (if exists) has a README.txt/ pom.xml/build.xml at the same level where the src directory exists and to check whether the resources directory (inside the src) contains any files.