Suggestion: structure the repository more clearly

[matthias-ronge]

I was thinking about how to structure the Kitodo.Production repository more clearly. The result is the following:

📁 docs
   📁 3.0
      📁 administration
      📁 development
      📁 use
   📁 3.1
      📁 administration
      📁 development
      📁 use
   📁 latest
      📁 administration
      📁 development
      📁 use
📁 folders
   📁 config
   📁 diagrams
   📁 logs
   📁 messages
   📁 metadata
   📁 modules
   📁 rulesets
   📁 scripts
   📁 temp
   📁 users
   📁 xslt
📁 libs
   📁 lib-api
   📁 lib-datamanagement
   📁 module-command
   📁 module-dataeditor
   📁 module-dataformat
   📁 module-docket
   📁 module-filemanagement
   📁 module-imagemanagement
   📁 module-longtimepreservationvalidation
   📁 module-persistentidentifier
   📁 module-schemaconverter
   📁 module-sruimport
   📁 module-validation
   📁 module-xmlschemaconverter
📁 webapp

docs/ This folder contains documentation for users, administrators and developers. A copy with version number is created as part of a release. The developers continue to edit the version under "latest". The documentation is configured to be visible in Read The Docs or equivalent.

folders/ Production is heavily based on the file system. This folder contains templates of the file system folders required for operation, some with templates of the required configuration files. (Git cannot save empty folders. An empty folder is created in Git by creating a .gitignore file in that folder that just ignores itself.)

libs/ This folder contains the sources of the libraries, also called modules, which are compiled separately and sometimes dynamically loaded at runtime. Libraries that are only compiled and must be available in the class path are given the lib- prefix. Modules that are loaded via the module loader are given the module- prefix.

webapp/ This folder is the source code of the web application called Kitodo.Production.

[henning-gerhardt]

In my opinion: your suggestion is nod bad but even not good.

• "docs" : ok, if you need version specific documentation but you will have some documentation which be the same for many versions
• "folders": This is a ugly naming but this should be decided later. Content can maybe stay here.
• "libs": In my opinion all the modules should go away from the main repository to their own repositories and are maintained there. Maybe the can be visible here as integrated git sub modules but I'm not familiar with the git sub modules usage (last time I looked into it, it was recommend to not use them in a productive way).
• "webapps": the application code is more then only "webapps" - even the core of Kitodo.Production is more and in parts already but not full parted into modules.

My biggest issue with this "new" structure is: is this still possible to build the application with maven without a GUI? For me it looks like a folder structure which is created by Eclipse application and only useful if you use Eclipse as other GUIs did not use this folder structure.

[matthias-ronge]

This is only about a new arrangement of the orders in the Git repository, this has nothing to do with Eclipse. Yes, I think something needs to be changed in the Maven settings. That would be part of the adaptation.

[matthias-ronge]

• "docs": I agree that the latest version of the documentation should be sufficient
• "folders": Maybe "var"?
• "libs": as they are just part of the source code, not real libraries, and their interface can change deliberately during development, they must be in sync while developing. So putting them in a extra repository isn’t a good choice for development.
• "webapps" here is meant as a name for the folder containing what we call the core, what we currently keep in the folder "/Kitodo". Without "diagrams", "rulesets", "scripts" (move to "folders") and "setup" (should be in the documentation)