Possy was created based on Boris's idea to print out tasks, bugs and other issues on POS printers (e.g. Epson TM-T20II) instead of using Post-it®, or print it on regular paper using the scissor.
Possy is intended to be used as addition for physical Scrum and Kanban boards. Read this blog post for further information.
- possy-daemon
- creates printable media out of print requests and talks to connected printers
- possy-service
- user interface to create print requests, contains Planner
- CUPS (print platform)
- see Installation & Configuration Guide for setup
- Providers like Jira, GitHub, etc.
- currently only Jira supported
The daemon part connects to a possy-service and fetches print requests (simply text or image content). For each print request a PDF will be generated and printed via CUPS to specific POS printers.
The daemon might run in a different network than possy-service. The deamon needs to reach possy-service over network, but not vice versa.
The daemon job might run on a Pi.
The service is a Vaadin frontend, which creates print requests either by retrieving content from different providers (e.g. Jira) or manually entered issues by users.
Possy knows 4 different types of issues:
- Stories
- Tasks
- Bugs
- Freeform (like a note)
An issue type is mapped to a specific printer (currently up to 3 different printers possible):
- Stories -> white
- Tasks -> white
- Bugs -> pink
- Freeform -> yellow
We provide a demo installation hosted on Heroku without real physical connected printers to test the user interface of possy-service. Please note the application might need some time to load initially, because apps on Heroku's free tier are going to sleep after some time of inactivity.
- possy-service
- possy-daemon
- just shows a very basic webpage with version information
You want to contribute? Great! Thanks for being awesome! Please see the project related issues before you start coding. Pull requests are always welcome!
In short, we provide an .editorconfig
file.
For more information please have a look at https://editorconfig.org/.
- Build with Maven
./mvnw clean verify
- Run application using
./mvnw spring-boot:run
or directly running Application class from your IDE - To build with production profile execute
./mvnw clean verify -Pprod -DskipTests
- Clone the repository with git
- Execute
./mvnw release:prepare release:clean
Example prompt:Preparing a release goes through the following release phases:[INFO] Checking dependencies and plugins for snapshots ... What is the release version for "possy"? (net.g24.possy:reactor) 1.0.2: : 1.0.2 What is SCM release tag or label for "possy"? (net.g24.possy:reactor) v1.0.2-SNAPSHOT: : v1.0.2 What is the new development version for "possy"? (net.g24.possy:reactor) 1.0.3-SNAPSHOT: : 1.0.3-SNAPSHOT
- Check that there are no uncommitted changes in the sources
- Check that there are no SNAPSHOT dependencies
- Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
- Transform the SCM information in the POM to include the final destination of the tag
- Run the project tests against the modified POMs to confirm everything is in working order
- Commit the modified POMs
- Tag the code in the SCM with a version name (this will be prompted for)
- Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
- Commit the modified POMs
- If everything was successful in step 2 a Docker image with the provided version tag (e.g. v1.0.0) will get built automatically by CI/CD now
- Optional: Go to GitHub releases page and provide a changelog