Add directory monitor for Latex citations

[LoayGhreeb]

Closes #10585.

• Added directory monitor to automatically update LaTeX citations when a LaTeX file is created, removed, or modified.
• Ignored parsing nested files (include or input commands). All .tex files in the selected directory and its subdirectories are parsed. This will be okay if there are no include commands referencing files outside the selected directory.
• How can I set a listener for the citation key changes? This is needed to update the citation list without selecting another entry and coming back again if the cite key changes.

preview.mp4

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[koppor]

Oh, wow! Did not expect that much changes to fix the code.

Very minor comments. Need to try out and to read the code inside IntelliJ.

I think, tests are hard for that one; thus it is OK not to have any test. -- However, maybe with @tempdir and some files.write things there could be tests?

[koppor]

@calixtus Can you check if the file DirectoryMonitor should reside in StateManager or if we should move it to Globals (similar to fileUpdateMonitor).

[calixtus]

Neither.

Globals is deprecated and is annoted as such. It shall not be used at all. We are working towards dissolving that class.

StateManager is not the new Globals.
The directory manager should be injected by constructor or in a view by the viewloader.

[calixtus]

Can the File update monitor and the DirectoryMonitor be merged to a more generic class?

[koppor]

Note that Globals points to StateManager:

/**
 * @deprecated try to use {@link StateManager} and {@link org.jabref.preferences.PreferencesService}
 */

---

We need a "Global" DirectoryMonitor. Would you place it in org.jabref.gui.DefaultInjector and then add a shutdown method to it?

We need to have a full lifecycle of DirectoryMonitor. Creation, running, and shutdown. There currently is no migration guide at org.jabref.gui.Globals#shutdownThreadPools

To keep things going, I vote to move the currently directoryMonitor code into Globals and do a refactoring towards dependency injection afterwards.

---

Also the more generic ones migration away from FileUpdateMonitor to Apache Commons IO or other classes should be done later. Otherwise, IMHO the PR blows up only because of "clean code".

---

Side comment: Injector.registerExistingAndInject(this); is a neat thing. I wonder why we don't use that more often :p.

[calixtus]

Lets go for Globals and then refactor it afterwards, so this PR keeps its focus,

[LoayGhreeb]

I think, tests are hard for that one; thus it is OK not to have any test. -- However, maybe with @tempdir and some files.write things there could be tests?

Thinking about testing, what aspects we should cover?

• Should we test that the listener works after a modification in a file? In my opinion, this is not necessary as it is already handled by Apache Commons IO.
• Do we need to test the parser result after a modification in a file? This is already tested in the LaTeX parser.

What are your thoughts on this?

[koppor]

What are your thoughts on this?

I was thinking about more an "integration test" (or "system test" how JavaFX calls it; or "End-to-end test"). The separate parts are tested, but the combination you are doing in this PR is not tested.

[koppor]

Tried out, works great!