Release 1.0.5

.github/workflows/maven.yml

@@ -0,0 +1,25 @@
+# This workflow will build a Java project with Maven
+# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven
+
+name: Java CI with Maven
+
+on:
+  push:
+    branches: [ develop ]
+  pull_request:
+    branches: [ develop ]
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v2
+    - name: Set up JDK 11
+      uses: actions/setup-java@v2
+      with:
+        java-version: '11'
+        distribution: 'adopt'
+    - name: Build with Maven
+      run: mvn -B package

.gitignore

@@ -23,3 +23,5 @@ build/
 
 ### VS Code ###
 .vscode/
+
+osmt*.env

CODE-OF-CONDUCT.md

@@ -0,0 +1,92 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of
+experience, education, socio-economic status, nationality, personal appearance,
+race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+*   Using welcoming and inclusive language
+*   Being respectful of differing viewpoints and experiences
+*   Gracefully accepting constructive criticism
+*   Focusing on what is best for the community
+*   Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+*   The use of sexualized language or imagery and unwelcome sexual attention or
+    advances
+*   Trolling, insulting/derogatory comments, and personal or political attacks
+*   Public or private harassment
+*   Publishing others' private information, such as a physical or electronic
+    address, without explicit permission
+*   Other conduct which could reasonably be considered inappropriate in a
+    professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+This Code of Conduct also applies outside the project spaces when the Project
+Steward has a reasonable belief that an individual's behavior may have a
+negative impact on the project or its community.
+
+## Conflict Resolution
+
+We do not believe that all conflict is bad; healthy debate and disagreement
+often yield positive results. However, it is never okay to be disrespectful or
+to engage in behavior that violates the project’s code of conduct.
+
+If you see someone violating the code of conduct, you are encouraged to address
+the behavior directly with those involved. Many issues can be resolved quickly
+and easily, and this gives people more control over the outcome of their
+dispute. If you are unable to resolve the matter for any reason, or if the
+behavior is threatening or harassing, report it. We are dedicated to providing
+an environment where participants feel welcome and safe.
+
+Reports should be directed to opensource@wgu.edu. All complaints will be reviewed
+and investigated and will result in a response that is deemed necessary and
+appropriate to the circumstances. The project team is obligated to maintain
+confidentiality with regard to the reporter of an incident. Further details of
+specific enforcement policies may be posted separately.
+
+We will investigate every complaint, but you may not receive a direct response.
+We will use our discretion in determining when and how to follow up on reported
+incidents, which may range from not taking action to permanent expulsion from
+the project and project-sponsored spaces. We will notify the accused of the
+report and provide them an opportunity to discuss it before any action is taken.
+The identity of the reporter will be omitted from the details of the report
+supplied to the accused. In potentially harmful situations, such as ongoing
+harassment or threats to anyone's safety, we may take action without notice.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html,
+and it is licensed under the CC BY 4.0 License, the terms of which are available at
+https://creativecommons.org/licenses/by/4.0/legalcode.

CONTRIBUTING.md

@@ -0,0 +1,101 @@
+# How to Contribute
+Never made an open source contribution before? Wondering how contributions work in our project? Here's a quick rundown!
+
+## Code of Conduct
+This project adheres to our [code of conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
+
+## Issue Tracking
+We use GitHub's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues).
+- You can submit issues for this project. Please do a courtesy search to verify that your issue is not already being tracked. If you have additional context for an existing issue, please add that with comments.
+- When you are looking for issues to work on, please notice if the issue already has an "Assignee". We are still developing how to manage ownership of a given issue.
+- Issues have labels describing what kind of changes are involved. GitHub search makes it easy to use these labels to find issues or pull requests you're interested in. Each label is listed with search links for finding open items with that label. We encourage you to read about other search filters to help you write more focused queries.
+
+- If you don't feel ready to make a code contribution yet, no problem! Check out the [existing issues](https://github.com/wgu-opensource/osmt/issues) to see if an issue exists already for the change you want.
+
+### Expectations for contributed code
+- OSMT project uses Kotlin 1.3.72 and Angular Front-end 10.0, with MySQL DB, redis and Elasticsearch. See the [Architecture](README.md#architecture) section in the README file.
+- Contributed code needs to follow appropriate style guides. Coding style isn't only a matter of preference, but is essential in managing an effective branching and release strategy. Trivial or unrelated code changes create merge conflicts, and introduce risk and wasted time in resolving them.
+  - Kotlin - https://developer.android.com/kotlin/style-guide
+  - Angular - https://angular.io/guide/styleguide
+- All code changes should be relevant to the issue/feature at hand. Avoid unrelated changes, like IDE import sorting or unrelated whitespace changes.
+  - Changes that are ["boy scouting"](https://headspring.com/2020/01/27/clean-code-conundrum/) (code improvements that leave an area cleaner than you found it) should be separate from feature changes. Boy scouting changes may be disruptive to others, and should be coordinated with project maintainers.
+- All execution paths for new code should be covered by unit tests.
+  - Many IDEs will report on unit test coverage and call out any gaps. That said, reporting of test coverage doesn't mean that the tests are useful or effective. If you find a section of code is difficult to unit test, this may indicate the need for some refactoring. Non-trivial refactors should also be coordinated with project maintainers.
+
+#### Testing expectations
+- The OSMT project embraces the [Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html). Boiling this down:
+  - We want to test all execution paths with unit tests.
+    - Unit tests do not rely on any external services, network access, databases, or filesystem I/O, but rather use mocks when required. This also informs good object composition and design, facilitating healthy dependency injection/inversion of control.
+    - Unit test classes will be run by Maven in the "test" phase by the Surefire plugin, and need to end in "Test".
+  - We use integration tests as needed to stand up subsets of the application. These may require Docker containers or interactions between several components or services.
+    - Integration test classes will be run by Maven in the "verify" phase by the Failsafe plugin, and need to end in "IT". Failsafe has "pre-integration-test" and "post-integration-test" phases for standing up and tearing down integration test resources. The "post-integration-test" phase is always processed, regardless of test failures. This allows Maven to clean up and destroy integration test resources.
+  - We want to have as few E2E (end to end) tests as possible.
+    - Our E2E tests are implemented in Protractor as automated browser tests, and require walking through functionality on an actual OSMT instance. These are the most expensive and time-consuming tests. They are needed to ensure that layers of the application are wired up correctly, but should be used sparingly.
+
+## Release / Branching Strategy
+The OSMT project will follow the [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) model, with
+* Enhancement and bug fix work done on feature branches (```feature/branch-name```)
+* Feature branches merge into ```develop```, as the integration branch
+* Releases are cut from ```develop``` (as ```release-branch-name```), and merged back in to both ```master``` and ```develop```
+>
+
+### Using git with this project
+1. Use the project's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues) to find an issue that you want to address, or a feature that you would like to add.
+2. Clone the repository to your local machine using `git clone https://github.com/wgu-opensource/osmt.git` or `git@github.com:wgu-opensource/osmt.git` for SSH.
+3. Create a new branch for your fix using `git checkout origin/develop -b your-local-branch-name`.
+   - Note, make sure you only branch from `origin/develop`!
+4. Make the appropriate changes for the issue you are trying to address, or the feature that you want to add. Include appropriate test coverage.
+5. Use `git add insert-paths-of-changed-files-here` to stage the changed files for the commit.
+6. Use `git commit` to commit the contents of the index. This should open an editor; please provide a useful commit message (see below for [more about commit messages](#commit-message-format))
+7. On GitHub, OSMT uses a branching workflow, where committers create a feature branch containing the desired changes (rather than asking contributors to fork our GitHub repo). Push the changes to a feature branch in GitHub using `git push HEAD:origin feature/your-feature-branch-name`.
+  - A given branch should only have a single feature. Multiple unrelated features should handled by creating multiple feature branches.
+
+### Submit a Pull Request (PR)
+A ["Pull Request"](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) initiates a code review workflow in which OSMT project maintainers review your contributed code, and request additional changes or approve it for merging into a coming release.
+1. After pushing your commit to a feature branch on GitHub, please review it for any unexpected changes. When you are ready for a review, you can submit a pull request (GitHub will provide a button for this in the browser after you push).
+   - Provide a title for your pull request. It can be the same as the 1st line of your commit message.
+   - Provide a description for your pull request. It can be the same as the description in your commit message.
+   - It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it!
+2. Wait for the pull request to be reviewed by a maintainer.
+3. Make changes to the pull request if the reviewing maintainer recommends them. Push those changes to the same GitHub feature branch.
+4. Celebrate your success after your pull request is merged!
+
+### Commit Message Format
+Please format your commit messages with a summary line (50 characters or less), a blank line, and more detailed text explaining the commit.
+- Understand ahead of time that commits are often squashed, so commit messages may not last forever.
+- Speak to both others and your near-future self. Capture enough ephemeral context to understand why this commit exists.
+- Reference [GitHub issues](https://guides.github.com/features/issues/) whenever possible.
+
+#### Example commit message:
+_(with thanks to https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)_
+```
+Capitalized, short (50 chars or less) summary #
+
+More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase can get confused if you run the
+two together.
+
+Write your summary line in the imperative: "Fix bug" and not "Fixed bug"
+or "Fixes bug."  This convention matches up with commit messages generated
+by commands like git merge and git revert.
+
+Further paragraphs come after blank lines.
+
+- Bullet points are okay, too
+
+- Typically a hyphen or asterisk is used for the bullet, followed by a
+  single space, with blank lines in between, but conventions vary here
+
+- Use a hanging indent
+```
+
+### Tips
+- Keep changes small and focused. In the case of multiple bug fixes or unrelated features, create one branch and PR per feature. This makes it easier to review, merge, and potentially rollback changes.
+- Avoid unrelated code changes, even in a changed file. Imports and whitespace formatting are frequent unrelated changes.
+- Test coverage, test coverage, test coverage. 
+
+# Where can I go for help?
+Make sure you follow the README to clone the project and setup. If you need help, you can ask questions in our GitHub '[Discussions](https://github.com/wgu-opensource/osmt/discussions)' area.

Dockerfile

@@ -3,10 +3,9 @@
 ################
 FROM centos:centos8.3.2011 as osmt-base
 
-LABEL Maintainer="Francisco Gray, <fgray@concentricsky.com>"
+LABEL Maintainer="WGU / OSN"
 LABEL Version="1.0"
 
-ENV JAVA_VERSION=11.0.9.11
 ENV JAVA_HOME=/etc/alternatives/jre
 ENV USER=osmt
 ENV BASE_DIR=/opt/${USER}
@@ -15,7 +14,7 @@ ENV BASE_DIR=/opt/${USER}
 RUN /usr/bin/yum install -y epel-release \
     && /usr/bin/yum update -y \
     && /usr/bin/yum remove -y java-1.8.0-openjdk* \
-    && /usr/bin/yum install -y curl java-11-openjdk-headless-${JAVA_VERSION} wget
+    && /usr/bin/yum install -y curl java-11-openjdk wget
 
 # Add in configuration files
 ADD ./docker/etc /etc
@@ -33,19 +32,12 @@ RUN /usr/sbin/useradd -r -d ${BASE_DIR} -s /bin/bash ${USER} -k /etc/skel -m -U
 ###########################
 FROM osmt-base as build
 
-ENV JAVA_HOME=/etc/alternatives/jre
-ENV JAVA_VERSION=11.0.9.11
-ENV M2_VERSION=3.6.3
+ENV M2_VERSION=3.8.3
 ENV M2_HOME=/usr/local/maven
 ENV PATH=${M2_HOME}/bin:${PATH}
-ENV USER=osmt
-ENV BASE_DIR=/opt/${USER}
-
-# Install OpenJDK Development Packages
-RUN /usr/bin/yum install -y java-11-openjdk-devel-${JAVA_VERSION}
 
 # Download / Install Maven
-ADD https://www-eu.apache.org/dist/maven/maven-3/${M2_VERSION}/binaries/apache-maven-${M2_VERSION}-bin.tar.gz /usr/share/src/
+ADD https://dlcdn.apache.org/maven/maven-3/${M2_VERSION}/binaries/apache-maven-${M2_VERSION}-bin.tar.gz /usr/share/src/
 
 WORKDIR /usr/share/src
 
@@ -59,18 +51,14 @@ WORKDIR ${BASE_DIR}/build
 
 USER ${USER}
 
-RUN mvn clean package -Dmaven.test.skip.exec
+# The dockerfile-build Maven profile excludes certain api integration tests that require access to the Docker service.
+RUN mvn clean install -P dockerfile-build
 
 ######################
 ### PACKAGING IMAGE ##
 ######################
 FROM osmt-base
 
-ENV JAVA_HOME=/etc/alternatives/jre
-ENV JAVA_VERSION=11.0.9.11
-ENV USER=osmt
-ENV BASE_DIR=/opt/${USER}
-
 COPY --from=build --chown=${USER}:${USER} ${BASE_DIR}/build/api/target/osmt-*.jar ${BASE_DIR}/bin/osmt.jar
 
 ADD ./docker/ /${BASE_DIR}/