Tech debt weaver upgrade (#120)

* Add PR template (#119)

* Add PR template

* remove unnecessary test configuration inputs

* Add issue templates (#118)

* Update issue templates

* remove assignees field from issue templates

* Standardize the multiple forms of gitignore

* update contributing, replace deploying, update license and readme

* update dockerfile

* cleanup log files

* update weaver version and normalize pom

* update build workflow

* Use .gitignore based off of App Repos.

* Update readme and related files for consistency.

- Fix simple mistakes.
- Use long/full names in titles without acronyms.
- Leave most of the README.md design as-is for comparison against alternative methods.
- Fix license sentence.
- Fix line endings where needed.
- Use different documentation for cases where there is no `docker-compose` available (as in, no UI or App Repos).
- Some documents have the incorrect link styling, which doesn't work.
- Make readme and related files more consistent.

* Use project-specific name in docker deploy instructions.

* Make Dockerfile more consistent.

- Remove SOURCE_DIR when not needed.
- Always clean and clear apt cache to reduce docker disk usage.
- Make sure the SOURCE_DIR exists when not copying it wholesale.
- Remove any spurious new lines.

Co-authored-by: Kevin Day <kday@library.tamu.edu>
Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,37 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/pull_request_template.md

@@ -0,0 +1,37 @@
+# Description
+
+Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
+
+Fixes # (issue)
+
+## Type of change
+
+Please delete options that are not relevant.
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+# How Has This Been Tested?
+
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
+
+- [ ] Test A
+- [ ] Test B
+
+**Test Configuration**:
+* Toolchain:
+* SDK:
+
+# Checklist:
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] My changes generate no new warnings
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
+- [ ] Any dependent changes have been merged and published in downstream modules
+

.github/workflows/build.yml

@@ -7,10 +7,10 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
 
       - name: "Maven Cache"
-        uses: actions/cache@v2
+        uses: actions/cache@v3
         with:
           path: ~/.m2/repository
           key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
@@ -20,14 +20,14 @@ jobs:
         with:
           java-version: 11
 
-      - name: "Maven Tests"
+      - name: "Maven Test"
         run: mvn clean test jacoco:report coveralls:report -DdryRun=true
 
       - name: "Coverage Report"
         uses: MikeEdgar/github-action@raw_coverage_file
         with:
           github-token: ${{ secrets.github_token }}
-          path-to-file: 'target/coveralls.json'
+          path-to-file: './target/coveralls.json'
           coverage-format: raw
 
       - name: "Deploy GH-Pages"

.gitignore

@@ -1,12 +1,70 @@
-.apt_generated/
-target/
-.DS_Store
+### Git ###
+!.gitkeep
+
+
+### STS ###
+.apt_generated
 .classpath
 .factorypath
 .project
 .settings
 .springBeans
-*.log*
-bin/
+.sts4-cache
+
+
+### IntelliJ IDEA ###
+.idea
+*.iws
+*.iml
+*.ipr
+
+
+### NetBeans ###
+/nbproject/private/
+/nbbuild/
+/dist/
+/nbdist/
+
+/.nb-gradle/
+
+
+### VS Code ###
+.vscode/
+
+dump.rdb
+
+
+### OS Specific ###
+.DS_Store
+.tmp/
+
+tmp/
+
+
+### Maven ###
 logs/
-dump.rdb
+target/
+
+.classpth
+.mvn/timing.properties
+.mvn/wrapper/maven-wrapper.jar
+.project
+
+buildNumber.properties
+dependency-reduced-pom.xml
+pom.xml.next
+pom.xml.tag
+pom.xml.releaseBackup
+pom.xml.versionsBackup
+release.properties
+
+
+### Weaver ###
+dist/
+
+
+### Project Specific ###
+.env*
+
+!**/src/main/**
+!**/src/test/**

CONTRIBUTING.md

@@ -1,69 +1,65 @@
-# Contributing To IR IIIF Service
+<a name="readme-top"></a>
+# Contributing to Institutional Repository International Image Interoperability Framework Service
 
-Though IR IIIF Service is developed and maintained by Texas A&M University Libraries, we welcome community contributions. Involvement in IR IIIF Service can take many forms:
+Though *Institutional Repository International Image Interoperability Framework (IRIIIF) Service* is developed and maintained by Texas A&M University Libraries, we welcome community contributions.
+Involvement in *IRIIIF Service* can take many forms.
 
-#### Using IR IIIF Service
+<div align="right">(<a href="#readme-top">back to top</a>)</div>
 
-Deploying IR IIIF Service and trying it out at your own institution is itself a way of contributing to the development process. For more information on deployment strategies please see the [relevant documentation](https://github.com/TAMULib/IRIIIFService/blob/master/README.md).
 
-#### Filing Issues
+## Using
 
-Once you are using IR IIIF Service the creation of new issues through Github is a major method of contribution towards IR IIIF Service development. Issues can be motivated by the discovery of a bug in the software, or by the desire to see either new features added to cap or existing features behaving differently.
+Deploying *IRIIIF Service* and trying it out at your own institution is itself a way of contributing to the development process.
+For more information on deployment strategies please see the [Deployment Guide][deployment-guide].
 
-These three categories of issue can be submitted using the following template:
+<div align="right">(<a href="#readme-top">back to top</a>)</div>
 
-    [*] Bug Report
-    [] Feature Enhancement
-    [] Feature Request
 
-    Current Behavior:
+## Filing Issues
 
-    [A description of the current behavior. This could include a list of steps to reproduce in the instance of a 
-    Bug Report, and can be 'N/A' for Feature Requests]
+Once you are using *IRIIIF Service* the creation of new issues through GitHub is a major method of contribution towards *IRIIIF Service* development.
+Issues can be motivated by the discovery of a bug in the software, or by the desire to see either new features added or see changes to existing features.
 
-    Desired Behavior:
+There are two primary types of issues:
+1. Bug Report
+2. Feature Request
 
-    [A description of the expected/desired behavior of the application]
+A **Bug Report** involves a problem with the existing software or a **Feature** is not working as designed or expected.
 
+A **Feature** involves new functionality or behavior.
 
-    Relevant Information:
+<div align="right">(<a href="#readme-top">back to top</a>)</div>
 
-    [This section can include relevant error messages, or links to information that pertains to the issue]
 
-Once an issue has been filed it will be curated by a IR IIIF Service developer and receive the appropriate labeling.
+## Creating a Pull Request
 
-#### Creating Pull Requests
+Community code and documentation contributions are welcome and should take the form of a **GitHub Pull Request** (*PR*).
+Each *PR* will need to be reviewed by a *IRIIIF Service* developer.
+A review will result in the *PR* being accepted and merged, a descriptive request for changes, or the *PR* being closed along with a detailed explanation.
 
-Community code and documentation contributions are welcome, and should take the form of a Github Pull Request (PR). Each PR will need to be reviewed by a IR IIIF Service developer. A review will result in the PR being accepted and merged, a descriptive request for changes, or the PR being closed along with a detailed explanation.
+It is our intention to maintain labeling on issues that are deemed to be low difficulty in order to provide a good point of entry for those looking to begin contributing code or documentation.
 
-It is our intention to maintain labeling on issues that are deemed to be low difficulty, in order to provide a good point of entry for those looking to begin contributing code or documentation.
+A *PR* description should include a list of the specific issues resolved, the predicted *semantic versioning* impact of the changes, and a description which characterizes the nature of the changes made.
+When creating a *PR*, an issue template is automatically provided to simplify this process.
 
-A PR description should include a list of the specific issues resolved, the predicted semantic versioning impact of the changes and a description which characterizes the nature of the changes made.
+For more information about *semantic versioning* please see [Semantic Versioning Website][semantic-versioning].
+In general keep in mind:
 
-For more information about semantic versioning please see [this reference](https://semver.org/). In general keep in mind:
+- A **Major Change** is a breaking change that is not backwards compatible.
+- A **Minor Change** is a non-breaking change that is backwards compatible to the last **Major Change**.
+- A **Patch** is a trivial change or bug fix that should not impact compatibility.
 
--   A Major Change is a breaking change that is not backwards compatible.
--   A Minor Change is a non breaking change that is backwards compatible to the last major change.
--   A Patch is a trivial change or bug fix that should not impact compatibility
+<div align="right">(<a href="#readme-top">back to top</a>)</div>
 
-Please confirm you PR description to the following template:
 
-    Resolves:
+## Good Luck!
 
-    - [List of # references to specific issues addressed by this PR]
+We look forward to seeing your contributions.
+If you have any additional questions please contact the *IRIIIF Service* developers at helpdesk@library.tamu.edu.
 
-    Changes:
+<div align="right">(<a href="#readme-top">back to top</a>)</div>
 
-    [*] Major
-    [] Minor
-    [] Patch
 
-    [A description of the approach taken to resolving those issues]
-
-In addition to a well formatted PR we would also appreciate granular commits with descriptive messages. For instance a good commit message may be `Moved /foo endpoint logic into a FooService`, whereas `Everything I did Friday` is less granular or descriptive.
-
-If your commits do not conform to these recommendations you might consider rebasing your PR. Instructions for how this might work can be found [here](https://help.github.com/articles/about-git-rebase/).
-
-#### Good Luck!
-
-We look forward to seeing your contributions. If you have any additional questions please contact the IR IIIF Service developers at [helpdesk@library.tamu.edu](<>).
+<!-- LINKS -->
+[deployment-guide]: DEPLOYING.md
+[semantic-versioning]: https://semver.org/