Merge pull request #356 from utPLSQL/release/v3.0.1

Release/v3.0.1

.travis.yml

@@ -22,7 +22,7 @@ env:
   global:
     - UT3_OWNER=ut3
     - UT3_OWNER_PASSWORD=ut3
-    - UT3_USER=ut3_user
+    - UT3_USER="UT3\$USER#"
     - UT3_USER_PASSWORD=ut3
     - UT3_TABLESPACE=users
     # Environment for building a release
@@ -80,8 +80,10 @@ deploy:
   provider: releases
   api_key: $github_api_token
   file:
-     - utPLSQL${UTPLSQL_BUILD_VERSION}.zip
-     - utPLSQL${UTPLSQL_BUILD_VERSION}.tar.gz
+     - utPLSQL.zip
+     - utPLSQL.tar.gz
+     - utPLSQL.zip.md5
+     - utPLSQL.tar.gz.md5
   skip_cleanup: true
   on:
      repo: ${UTPLSQL_REPO}

.travis/build_release_archive.sh

@@ -9,7 +9,11 @@ mv -f .gitattributes.release .gitattributes
 git add .
 git commit -m "tmp commit for building a release archive"
 
-git archive --prefix="utPLSQL${UTPLSQL_BUILD_VERSION}"/ -o "utPLSQL${UTPLSQL_BUILD_VERSION}".zip    --format=zip    HEAD
-git archive --prefix="utPLSQL${UTPLSQL_BUILD_VERSION}"/ -o "utPLSQL${UTPLSQL_BUILD_VERSION}".tar.gz --format=tar.gz HEAD
+# git archive --prefix="utPLSQL${UTPLSQL_BUILD_VERSION}"/ -o "utPLSQL${UTPLSQL_BUILD_VERSION}".zip    --format=zip    HEAD
+# git archive --prefix="utPLSQL${UTPLSQL_BUILD_VERSION}"/ -o "utPLSQL${UTPLSQL_BUILD_VERSION}".tar.gz --format=tar.gz HEAD
 
+git archive --prefix=utPLSQL/ -o utPLSQL.zip    --format=zip    HEAD
+git archive --prefix=utPLSQL/ -o utPLSQL.tar.gz --format=tar.gz HEAD
+md5sum utPLSQL.zip  --tag > utPLSQL.zip.md5
+md5sum utPLSQL.tar.gz  --tag > utPLSQL.tar.gz.md5
 

.travis/get_project_build_version.sh

@@ -1,2 +1,2 @@
 #!/usr/bin/env bash
-echo `sed -r "s/(v?[0-9]+\.)([0-9]+\.)([0-9]+)(-.*)/\1\2\3\.${UTPLSQL_BUILD_NO}\4/" <<< "${UTPLSQL_VERSION}"`
+echo `sed -r "s/(v?[0-9]+\.)([0-9]+\.)([0-9]+)(-.*)?/\1\2\3\.${UTPLSQL_BUILD_NO}\4/" <<< "${UTPLSQL_VERSION}"`

.travis/install.sh

@@ -11,7 +11,11 @@ set verify off
 @../source/create_utplsql_owner.sql $UT3_OWNER $UT3_OWNER_PASSWORD $UT3_TABLESPACE
 --needed for Mystats script to work
 grant select any dictionary to $UT3_OWNER;
+--Needed for testing a coverage outside ut3_owner.
+grant create any procedure, execute any procedure to $UT3_OWNER;
+
 @../source/create_utplsql_owner.sql $UT3_USER $UT3_USER_PASSWORD $UT3_TABLESPACE
+
 cd ..
 
 --enable plsql debug

.travis/push_docs_to_gh_pages.sh

@@ -20,7 +20,7 @@ LATEST_DOCS_BRANCH="develop"
 # Since we are running job matrix, only thie first job slave will need to do the work
 if [[ "${TRAVIS_JOB_NUMBER}" =~ \.1$ ]]; then
   # We don't want a pull request automatically updating the repository
-  if [ "$TRAVIS_PULL_REQUEST" == "false" ] && [ "${CURRENT_BRANCH}" == "${LATEST_DOCS_BRANCH}" ]; then
+  if [ "$TRAVIS_PULL_REQUEST" == "false" ] && { [ "${CURRENT_BRANCH}" == "${LATEST_DOCS_BRANCH}" ] || [ -n "${TRAVIS_TAG}" ]; }; then
 
     # ENV Variable checks are to help with configuration troubleshooting, they silently exit with unique message.
     # Anyone one of them not set can be used to turn off this functionality.

VERSION

@@ -1 +1 @@
-v3.0.0
+v3.0.1

development/readme.md

@@ -1,6 +1,6 @@
 # Build Folder
 
- Contains the build scripts that can be run locally on a developers machine to build run and test utPLSQL.  
+ Contains the build scripts that can be run locally on a developer's machine to build, run and test utPLSQL.  
 
- These scripts are also used by Jenkins Continuous integration server to check each pull request before it is merged.
+ These scripts are also used by the Jenkins Continuous Integration server to check each pull request before it is merged.
 

development/releasing.md

@@ -1,11 +1,11 @@
-Release process is automated in following way:
-1) with every build, the build process on travis updatse files with appropriate version number before deployment into db.
+The release process is automated in the following way:
+1) With every build, the build process on Travis updates files with an appropriate version number before deployment into the database.
    This is to confirm that the update of versions works properly.
-2) when build is executed on a branch named `release/v1.2.3-something` then additional steps are taken:
-    - project version in files: `sonar-project.properties`, `VERSION` is updated from the version number derived from release branch
-    - changes on those two files are committed and and pushed - this should happen only once, when the release branch is initially created on the main repo
+2) When a build is executed on a branch named `release/v1.2.3-something` then additional steps are taken:
+    - the project version in files: `sonar-project.properties`, `VERSION` is updated from the version number derived from the release branch
+    - changes to those two files are committed and pushed - this should happen only once, when the release branch is initially created on the main repo
 3) To create a release, just create a tag on the code to be released. The tag name must match the regex pattern: `^v[0-9]+\.[0-9]+\.[0-9]+.*$`
    - When a tag build is executed, the documentation is built and files are uploaded to the tag.
    - The version number is derived from the tag name.
-4) Release version do not provide access to unversioned source files (the default zip file from github is empty). 
-   The sources for release are provided in separate zip files delivered from travis build process.
+4) The release version does not provide access to unversioned source files (the default zip file from GitHub is empty). 
+   The sources for release are provided in separate zip files delivered from the Travis build process.

docs/about/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 ## How to contribute ##
 
-The following are the guidelines, everyone should use to contribute to utPLSQL.  
+The following are the guidelines everyone should use to contribute to utPLSQL.  
 Changes are welcome from all members of the Community. 
 
 ## Getting Started ##

docs/about/support.md

@@ -1,4 +1,4 @@
 # How to get support
 
-- Feel free post questions, bugs or issues in the [issues area of GitHub](https://github.com/utPLSQL/utPLSQL/issues).
-- Join developers the [utPLSQL team](http://utplsql-slack-invite.herokuapp.com) on [Slack](https://slack.com/)
+- Feel free to post questions, bugs or issues in the [issues area of GitHub](https://github.com/utPLSQL/utPLSQL/issues)
+- Join developers at the [utPLSQL team](http://utplsql-slack-invite.herokuapp.com) on [Slack](https://slack.com/)

docs/userguide/annotations.md

@@ -17,9 +17,9 @@ Procedure annotations are defined right before the procedure they reference, no
 
 If a package specification contains `%suite` annotation, it is treated as a test package and processed by the framework.
 
-Some annotations accept parameters like `%suite`, `%test` `%displayname`. The parameters for annotations need to be placed in brackets. Values for parameters should be provided without any quotation marks.
+Some annotations accept parameters like `%suite`, `%test` and `%displayname`. The parameters for annotations need to be placed in brackets. Values for parameters should be provided without any quotation marks.
 
-# <a name="example"></a>Example of annotated test package
+# <a name="example"></a>Example of an annotated test package
 
 ```sql
 create or replace package test_pkg is
@@ -87,9 +87,9 @@ end test_pkg;
 
 It is very likely that the application for which you are going to introduce tests consists of many different packages or procedures/functions. Usually procedures can be logically grouped inside a package, there also might be several logical groups of procedure in a single package or even packages themselves might relate to a common module.
 
-Lets say you have a complex insurance application the operates with policies, claims and payments. The payment module contains several packages for payment recognition, charging, planning etc. The payment recognition module among others contains a complex `recognize_payment` procedure that associates received money to the policies.
+Let's say you have a complex insurance application that deals with policies, claims and payments. The payment module contains several packages for payment recognition, charging, planning etc. The payment recognition module among others contains a complex `recognize_payment` procedure that associates received money to the policies.
 
-If you want to create tests for your application it is recommended to structure your tests similarly to the logical structure of you application. So you end up with something like:
+If you want to create tests for your application it is recommended to structure your tests similarly to the logical structure of your application. So you end up with something like:
 * Integration tests
   *   Policy tests
   *   Claim tests
@@ -98,7 +98,7 @@ If you want to create tests for your application it is recommended to structure
     * Payments set off
     * Payouts 
 
-The `%suitepath` annotation is used for such grouping. Even though test packages are defined in a flat structure the `%suitepath` is used by the framework to form a hierarchical structure of them. Your payments recognition test package might look like:
+The `%suitepath` annotation is used for such grouping. Even though test packages are defined in a flat structure the `%suitepath` is used by the framework to form them into a hierarchical structure. Your payments recognition test package might look like:
 
 ```sql
 create or replace package test_payment_recognition as
@@ -136,10 +136,10 @@ create or replace package test_payment_set_off as
 end test_payment_set_off;
 ```
 
-When you execute tests for your application, the framework constructs test suite for each test package. Then in combines suites into grouping suites by the `%suitepath` annotation value so that the fully qualified path to the `recognize_by_num` procedure is `USER:payments.test_payment_recognition.test_recognize_by_num`. If any of its expectations fails then the test is marked as failed, also the `test_payment_recognition` suite, the parent suite `payments` and the whole run is marked as failed.
-The test report indicates which expectation has failed on the payments module. The payments recognition submodule is causing the failure as `recognize_by_num` has is not meeting the expectations of the test. Grouping tests into modules and submodules using the `%suitepath` annotation allows you to logically organize your projects flat structure of packages int functional groups. 
+When you execute tests for your application, the framework constructs a test suite for each test package. Then it combines suites into grouping suites by the `%suitepath` annotation value so that the fully qualified path to the `recognize_by_num` procedure is `USER:payments.test_payment_recognition.test_recognize_by_num`. If any of its expectations fails then the test is marked as failed, also the `test_payment_recognition` suite, the parent suite `payments` and the whole run is marked as failed.
+The test report indicates which expectation has failed on the payments module. The payments recognition submodule is causing the failure as `recognize_by_num` has not met the expectations of the test. Grouping tests into modules and submodules using the `%suitepath` annotation allows you to logically organize your project's flat structure of packages into functional groups. 
 
-Additional advantage of such grouping is the fact that every element level of the grouping can be an actual unit test package containing module level common setup for all of the submodules. So in addition to the packages mentioned above you could have following package.
+An additional advantage of such grouping is the fact that every element level of the grouping can be an actual unit test package containing a common module level setup for all of the submodules. So in addition to the packages mentioned above you could have the following package.
 ```sql
 create or replace package payments as
 
@@ -153,38 +153,38 @@ create or replace package payments as
 
 end payments;
 ```
-A `%suitepath` can be provided in tree ways:
-* schema - execute all test in the schema
-* [schema]:suite1[.suite2][.suite3]...[.procedure] - execute all tests in all suites from suite1[.suite2][.suite3]...[.procedure] path. If schema is not provided, then current schema is used. Example: `:all.rooms_tests`.
-* [schema.]package[.procedure] - execute all tests in the test package provided. The whole hierarchy of suites in the schema is build before, all before/after hooks of partn suites for th provided suite package are executed as well. Example: `tests.test_contact.test_last_name_validator` or simply `test_contact.test_last_name_validator` if `tests` is the current schema.
+A `%suitepath` can be provided in three ways:
+* schema - execute all tests in the schema
+* [schema]:suite1[.suite2][.suite3]...[.procedure] - execute all tests in all suites from suite1[.suite2][.suite3]...[.procedure] path. If schema is not provided, then the current schema is used. Example: `:all.rooms_tests`
+* [schema.]package[.procedure] - execute all tests in the specified test package. The whole hierarchy of suites in the schema is built before all before/after hooks or part suites for the provided suite package are executed as well. Example: `tests.test_contact.test_last_name_validator` or simply `test_contact.test_last_name_validator` if `tests` is the current schema.
 
 # Using automatic rollbacks in tests
 
-By default, changes performed by every setup, cleanup and test procedure is isolated using savepoint.
-This solution is suitable for use-cases, where the code that is getting tested as well as the unit tests themselves do not use transaction control (commit/rollback) or DDL commands.
+By default, changes performed by every setup, cleanup and test procedure are isolated by savepoints.
+This solution is suitable for use-cases where the code that is getting tested as well as the unit tests themselves do not use transaction control (commit/rollback) or DDL commands.
 
 In general, your unit tests should not use transaction control as long as the code you are testing is not using it too.
-Keeping the transactions uncommitted allows your changes to be isolated and the execution of tests is not impacting others that might be using a shared development database.
+Keeping the transactions uncommitted allows your changes to be isolated and the execution of tests does not impact others who might be using a shared development database.
 
-If you are in situation, where the code you are testing, is using transaction control (common case with ETL code), then your tests probably should not use the default automatic transaction control.
-In that case use the annotation `-- %rollback(manual)` on the suite level to disable automatic transaction control for entire suite.
+If you are in a situation where the code you are testing uses transaction control (common case with ETL code), then your tests probably should not use the default automatic transaction control.
+In that case use the annotation `-- %rollback(manual)` on the suite level to disable automatic transaction control for the entire suite.
 If you are using nested suites, you need to make sure that the entire suite all the way to the root is using manual transaction control.
 
 It is possible with utPLSQL to change the transaction control on individual suites or tests that are part of complex suite.
-It is strongly recommended not to have mixed transaction control in suite.
+It is strongly recommended not to have mixed transaction control in a suite.
 Mixed transaction control settings will not work properly when your suites are using shared setup/cleanup with beforeall, afterall, beforeeach or aftereach annotations.
-Your suite will most probably fail with error or warning on execution. Some of the automatic rollbacks will most probably fail to execute depending on the configuration you have.
+Your suite will most likely fail with error or warning on execution. Some of the automatic rollbacks will probably fail to execute depending on the configuration you have.
 
-In some cases it is needed to perform DDL as part of setup or cleanup for the tests. 
-It is recommended to move such DDL statements to a procedure with `pragma autonomous_transaction` to eliminate implicit commit in the main session that is executing all your tests.
-Doing so, allows your test to use automatic transaction control of the framework and release you from the burden of manual cleanup of data that was created or modified by test execution.
+In some cases it is necessary to perform DDL as part of setup or cleanup for the tests. 
+It is recommended to move such DDL statements to a procedure with `pragma autonomous_transaction` to eliminate implicit commits in the main session that is executing all your tests.
+Doing so allows your tests to use the framework's automatic transaction control and releases you from the burden of manual cleanup of data that was created or modified by test execution.
 
-When you are running test of code that is performing an explicit or implicit commit, you may set the test procedure to run in autonomous transaction with `pragma autonomous_transaction`.
-Keep in mind, that when your tests runs in autonomous transaction it will not see the data prepared in setup procedure unless the setup procedure committed the changes. 
+When you are testing code that performs explicit or implicit commits, you may set the test procedure to run as an autonomous transaction with `pragma autonomous_transaction`.
+Keep in mind that when your tests runs in autonomous transaction it will not see the data prepared in setup procedure unless the setup procedure committed the changes. 
 
 # Order of execution
 
-When processing the test suite `test_pkg` defined in [Example of annotated test package](#example), the execution will be done in the following order.
+When processing the test suite `test_pkg` defined in [Example of annotated test package](#example), the order of execution will be as follows.
 
 ```
   create a savepoint 'beforeall'