liturner/frederick

The name takes from Frederick the Great, a German general from the 1700s. Frederick is a open-source toolkit aimed at the German Technisches Hilfswerk Zugtrupp.

Download Frederick

Links

• Product Site
• GitHub Project

Project Type

• Maven
• Java 17
• VS Code (optionally)

Project Aims

We aim to provide a set of tools to help with the missions and deployments of the German Federal Agency for Technical Relief. The project aims to produce software which fulfills stringent security and data protection checks.

• Stability of the software is preferred over quantity of features.
• The software should only be configurable where necessary.
• The software is to be used in emergency situations. Pretty comes second to fast.

Architecture

The application aims to have a fairly minimalistic architecture, while still ensuring that future refactoring is not a nightmare. The GUI is generally separate from the application, and the individual windows or major components of the application do not communicate directly with one another, but rather through a central command and event system. The primary points of interest are:

• There is a single Application Service class which is not tied to the GUI or any major SDK. This is where all actions and events are consumed and produced. Future iterations may see this evolve into multiple services provided by modules. This class hides the data storage and logging from the user interfaces. This is a critical aspect to consider, as Unit Testing must be able to validate that the application always logs certain actions. (relevant for certification)
• Each window is treated like a plugin which adds a new view on the data. It does not add any new functionality! All functionality is handled by the "Application Service" class.
• Action Listeners should be limited to the main window frames, which themselves update their sub-components. This is purely for cognitive simplicity and may change if not strong enough as a tactic.
• GIS stuff (Geotools) is kept in a single package. The application should never become dependent on such a major SDK.
• GIS Layers are singletons. The application is deliberately static, and adding / removing data to and from the layers is well-defined enough that we can centralise the logic in classes which will only have one instance.

It is known that this architecture is not complete. As the application expands it will be updated to be more robust using a strong pattern. For the time being the intention is to spend some time developing the requirements of the application, before settling on a long term architecture.

Help

If you get stuck figuring out which module to require: https://stackoverflow.com/questions/74963898/how-do-i-discover-the-correct-java-11-module-names-for-my-geotools-project

frederick's Issues

The System must provide the functionality to define a Deployment Bullseye

Add maven-exec-plugin to the jpackage module

The intention is to ensure that the package command generates a JPackage, with no additional CLI from outside of maven

Create a seperate jar for taktische zeichen based on 256 png https://github.com/jonas-koeritz/Taktische-Zeichen

Remove actionListener system from the Database and transfer to Service class

The child modules such as the GUI Frames should not have access to the database module directly.

Bullseye style is not rendering correctly

The bullseye is a compound style, but only one stroke is showing. Figure out why.

Implement Java 9 Modules and cleanup package / class names

Now that there is a reasonable codebase, refactor to support Java Modules. Lock down a module per major window etc.

Add missing license information, ideally linking to their github license files

In the best case, find the open source projects and create some pull requests to ensure that future releases have their licenses correctly configured.

Can be considered done when third party license generation throws no errors.