Following the discussion from today's devcall, here comes an outline of our desired high-level architecture for JabRef and some data on the status quo. This is a refinement from our high-level documentation.
@JabRef/developers Please have a look, mention anything that you find worth remarking or discussing, and eventually I will update the high level documentation to reflect our desired architecture. Here is a screenshot from my architecture modeling tool for JabRef 3.4 (apologies for overlapping arrows and numbers, there's no possibility to avoid this tool-wise):
Arrows mark dependencies and the number of an arrow reflects the number of dependencies. Dashed arrows mark forbidden dependencies, whereas complete arrows mark allowed dependencies. The model depicts the desired architecture, not the actual architecture. I manually sorted all classes of jabref into these high-level packages, for instance the MetaData class should be in jabref.model and that would currently lead to forbidden dependencies from jabref.model to jabref.gui. Based on my sorting and the actual current source code, the architecture tool computes the number of dependencies between the packages.
The content of jabref.model, jabref.logic, and jabref.gui is described in our high-level documentation. On top of that jabref.globals should contain bootstrapping classes and global information (JabRefMain, Defaults, Globals, etc.). jabref.preferences should bundle the classes JabRefPreferences and JabRefPreferencesFilter. jabref.cli should bundle the CLI classes (already a top level package). According to the model, the only allowed dependencies in jabref should be:
jabref.logic -> jabref.model
jabref.globals -> everywhere
jabref.gui -> everywhere
jabref.cli -> jabref.preferences
jabref.cli -> jabref.globals
jabref.cli -> jabref.logic
jabref.cli -> jabref.model
This is an open discussion, any comments are welcome!
Following the discussion from today's devcall, here comes an outline of our desired high-level architecture for JabRef and some data on the status quo. This is a refinement from our high-level documentation.
@JabRef/developers Please have a look, mention anything that you find worth remarking or discussing, and eventually I will update the high level documentation to reflect our desired architecture. Here is a screenshot from my architecture modeling tool for JabRef 3.4 (apologies for overlapping arrows and numbers, there's no possibility to avoid this tool-wise):
Arrows mark dependencies and the number of an arrow reflects the number of dependencies. Dashed arrows mark forbidden dependencies, whereas complete arrows mark allowed dependencies. The model depicts the desired architecture, not the actual architecture. I manually sorted all classes of jabref into these high-level packages, for instance the
MetaDataclass should be injabref.modeland that would currently lead to forbidden dependencies fromjabref.modeltojabref.gui. Based on my sorting and the actual current source code, the architecture tool computes the number of dependencies between the packages.The content of
jabref.model,jabref.logic, andjabref.guiis described in our high-level documentation. On top of thatjabref.globalsshould contain bootstrapping classes and global information (JabRefMain,Defaults,Globals, etc.).jabref.preferencesshould bundle the classesJabRefPreferencesandJabRefPreferencesFilter.jabref.clishould bundle the CLI classes (already a top level package). According to the model, the only allowed dependencies in jabref should be:jabref.logic->jabref.modeljabref.globals->everywherejabref.gui->everywherejabref.cli->jabref.preferencesjabref.cli->jabref.globalsjabref.cli->jabref.logicjabref.cli->jabref.modelThis is an open discussion, any comments are welcome!