-
Notifications
You must be signed in to change notification settings - Fork 0
System Overview
The purpose of the system is to be a bibliography reference manager, using BibTex as its native file format. Diving a bit more into detail the system is quite extensive with a lot of functionality. Particularly useful features are for example the ability to extract citations from a LaTeX file, updating current citations from sources such as Crossref, and searching for new online sources.
The system architecture consists of 5 main packages. Namely: cli
, gui
, logic
, model
, and preferences
. Following will be descriptions of each package and how they depend on each-other. As explained in the official high-level documentation, the model
is the core of the architecture, where the rest of the packages are dependent on it (except preferences).
The text on the nodes are the package names. Arrows mean permitted dependencies. "Everywhere" means any class in any package.
The diagram illustrates that the project follows a hierarchical structure. For instance, an arrow between the gui
and logic
package means that the gui
is allowed to import and depend on classes within the logic
package. The arrows are directional, meaning that that same arrow does not imply that logic
may depend on gui
classes. Any imports "upwards" in the hierarchy are forbidden and a sign that the code should be refactored. The global classes (classes in the org.jabref
package, such as org.jabref.Globals
) can import anything but only be used in the interface packages.
As the core of the architecture, the primary purpose of model
is to be the package containing all the main data structures that is needed for the program to function. Looking at the sub-packages the most important ones are probably database
and entry
. The former containing classes such as BibDatabase
which is the representation of a .bib file, and the latter containing classes representing each database entry and its fields.
The logic
package is in the words of the developes responsible for all actions when it comes to the model
. This means that all reading/writing/manipulation and so on of the model
should be done through the logic
package. This in turn means that the only thing logic
is and should be dependent on is model
.
The package is well-structured and program functions are logically split into sub-packages. One example is the sub-package search
which contains the classes used when searching through a BibDatabase
for example. Or the importer
package which contains all classes used to import resources such as Google Scholar entries.
This package deals with everything related to the preferences the system's user has. The majority of the code that handles the preferences is located in the class JabRefPreferences
. The reason for having this package is because of the large amount of preferences, which requires a lot of code to keep track of.
As one can guess from the name of the package, cli handles the execution of the Command Line Interface version of the program. It also passes information to the gui
in case the program is started with additional arguments. The core of the cli logic is located in the ArugmentProcessor
class, which handles all the inputted arguments to the program. The class is therefore dependent on a lot of classes in the logic
and model
packages. The other class in this package worthy of mention is the JabRefCLI
class which handles the definition of CLI arguments and keeps track of Boolean values representing which arguments are being used.
This package handles everything regarding the Graphical User Interface of the program. All the components of the GUI are split into packages which makes them fairly easy to locate. Generally the structure of the files seems to be that a class containing GUI elements are named [componentName]View
and are then supplied with data from a corresponding ViewModel
class. Which leads one to believe that some form of a Model-view-viewmodel (MVVM) pattern is used, where the 'model' part is implemented in the model
and logic
packages. If time permitted it would be interesting to document each sub-package in gui
but since there are about 50 of them, it seems a bit out-of-scope.