Project Submission

Your project should include more than just source code. This section describes our expectations for the project artifacts that you will maintain in GitLab. Your completed project with all of the contents below describes everything that you need to submit for your project (see assessment for details).


This GitLab project is where you should keep track of everything that you do in this course! This includes meeting minutes, source code, scripts, documentation.

0. Project Setup

In the first week, you and your team must create a GitLab project. Visit and use the New Project wizard. You can create either a shared project, or store under a single person’s account.

  • Give it a meaningful name (note: a “project slug” is just a lowercase version of the name with no spaces).

  • Make the repository private so that it’s not visible to the rest of the class.

  • Add your Team Members and course staff as Developers on the project.

  • Finally, email the instructor with a list of team members and your repository URL.

GitLab New Project wizard GitLab New Project wizard

1. README (Landing Page)

You should have a markdown file in the root of your source code repository named This will serve as a landing-page for your project (i.e. its the first thing that users will see when visiting your project page!). It should contain the following sections.


## Goal
A brief description of your project. What is it? What does it do?

## Team Members
List each person's name and email address.

## Screenshots/Videos
Optional, but often helpful to have a screenshot or demo-video for new users.

## Quick-Start Instructions
Instructions. Details on how to install and launch your application. 

## Project Documents
Include a link to your Wiki pages, see below.

## Software Releases
Include a link to your Wiki pages, see below.

2. Wiki

Your GitLab project has a built-in Wiki, where you can store more complex documents and project executables.

2.1. Project Documents

Your project documents should go here, including:

  • Project proposal
  • Meeting minutes
  • Anything else that you wish to capture.

2.1. Software Releases

Each sprint should produce an installable and runnable version of your project, which should contain the features that were completed during the sprint. The output from a sprint should be a release-quality build of your product, which you will store in your project repository.

Your file (from above) should include links to the components of each software release. Your software release should include:

  • Release notes: a markdown or text file, containing at least:

    • the release date (which should be the sprint demo date)

    • the version of this release (which you increment for each release)

    • a list of changes that were included.

  • Installers: this is a packaged version of your application that a user could use to install your software. You should support installation on at least 2 platforms (pick two from Linux, Windows, macOS - whatever you have available).

    Acceptable forms of packaging include:

    • a zip or tar file that, when extracted, contains bin/ and lib/ directories, and a script that launches the application (produced from distZip or distTar tasks in Gradle).

    • an exe, dmg or pkg file that, when executed, installs the application (produced from JPackage task in Gradle ).

3. Source Code Repository

Source code and other assets required to build your application should be stored in your project’s source code repository. The structure should look something like this by the end of the term.

├── .gitignore
├── .gitlab-ci.yml
├── LICENSE.txt
├── application
│   ├── build.gradle
│   └── src
│       ├── main
│       │   ├── java
│       │   └── kotlin
│       └── test
│           └── java
├── buildSrc
│   ├── build.gradle
│   └── src
│       └── main
│           └── groovy
├── console
│   ├── build.gradle
│   └── src
│       └── main
│           ├── java
│           └── kotlin
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └──
├── gradlew
├── gradlew.bat
├── releases
│   └──
│   └── v0.1-installer.dmg
│   └── v0.1-installer.exe
│   └──
│   └── v0.2-installer.dmg
│   └── v0.2-installer.exe
├── server
│   ├── build.gradle
│   ├──
│   └── src
│       ├── main
│       │   ├── java
│       │   ├── kotlin
│       │   └── resources
│       └── test
│           └── kotlin
├── settings.gradle
└── shared
    ├── build.gradle
    └── src
        └── main
            ├── java
            └── kotlin

Most of your repository contains the source code and related documents for your project. It is recommended that you follow the structure provided above, which will build properly in GitLab CI/CD.