[UserStory] Add packaging task to the product build process

[vlazosar]

User Story

Essential components

• [x] Title describes the story
• [x] Stakeholder type is identified
• [ ] Outcome is described
• [ ] Rationale is explicit
• [ ] Acceptance criteria are verifiable and from the perspective of the stakeholder

Story

As a maintainer
I want a task within the Gradle build that packages the product for distribution
so that when run, it builds the product jar file (if necessary), copies it to an identified location in the repository, and renames it in accordance with the product specifications.

Acceptance Criteria

• Rule 1: The identified location is the root directory of the repository.
• Rule 2: The product jar filename is QualityTools.jar
• Rule 3: The build task is named package and invoked as gradle package
• Rule 4: The package task must not be invoked by the build task or other development tasks

Scenario 1

Given a copy of the project repository
when I run the build command gradlew package
then the product jar is built and copied to the top level of the repository as /QualityTools.jar.

Scenario 2

Given a copy of the project repository with an up-to-date build of the product jar
when I run the build command gradlew package
then the product jar is copied to the top level of the repository as /QualityTools.jar.

Supporting Information

See gradle documentation for help creating tasks. https://docs.gradle.org/current/userguide/tutorial_using_tasks.html

Dependencies

Dependents

43

[jreiser1]

@jody Can you assign me to this issue?

[alexrknowles]

@jody can you assign me to this issue?

[Bagel-Emperor]

@jody Can you assign me to this issue?

[jreiser1]

Would there be any problems with renaming the dist task which already exists in build.gradle to package? It appears that the dist task currently performs the desired functionality of this issue.

[jody]

If the product (which includes the code, build process, documentation, etc.) already meets the requirements for the issue, then all that needs to be done is to demonstrate that everything works as specified so we can close the issue.

[jody]

Looking at this issue, it is clear that it was never approved for the project. There's no "project" associated with the issue and the "Outcome", "Rationale", and "Acceptance Criteria" haven't been vetted.

Because this issue does not appear on the Project Board, it wasn't approved by the project. (Note that although anyone can create issues. Only the project maintainers can approve them for integration into the project workflow.)

If you are looking for issues that the project wants help with, please select from those in the ToDo column of the project board.