Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • V vadere
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 130
    • Issues 130
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 4
    • Merge requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • vadere
  • vadere
  • Issues
  • #243
Closed
Open
Issue created May 20, 2019 by Daniel Lehmberg@dlehmMaintainer

Organize all settings and properties in a central file

From discussion: @BZoennchen @hm-kleinmei

  • Find out what and where property files are read into Vadere (and actually used). Make a list and report files that seem irrelevant and seem subject to remove.
    • One example for a property file: the file VadereGui/resources/config/global_config.properties
    • Note: there can also be other file formats (not necessarily end with .properties)

Out aim is to centralise all "internal" properties (that are not given to the user)

  • Create this new central properties file in .ini format; use the ini4j package, maybe make a little research if there are better ones.
  • Translate all properties from properties (likely from different file formats) that are scattered in the Vadere project) into the new .ini format.
  • Read this new file into Vadere and define a class that returns the set options
  • Make this class globally accessible via a single object that is instantiated once via the singleton pattern

Current list of files that may contain relevant configutation

See also .java files where there seem relevant global configs. One such file is the class

  • DataProcessingJsonManager, there are many private static final which are hard coded, but could be in a central spot.
  • OutputFile contains settings about further info in the column name.

Current list of deprecated/unused setting files and locations

n/a (TODO)

Edited May 21, 2019 by Daniel Lehmberg
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking

LRZ Homepage | Datenschutz | Dokumentation und Betriebsbedingungen | Impressum