Implements #1664: group based on aux file

[tobiasdiez]

This PR implements #1664 by adding a group that contains all entries referenced in a given aux-file. So far the code is only a prototype, but it already works really well. What is missing is that changes in the aux file are automatically recognized and handled (this should be easy to accomplish). The user interface is very very basic and only contains a text field where the user can specify the path to the aux file (in light of the upcoming rewrite of the groups dialog in javafx #2643, I don't want to spent to much time at ui stuff).

I have two questions:

• The implementation so far is against our architecture. The new group (TexGroup) is in the model but uses the AuxParser from the logic. Any ideas how to resolve this issue? More and more, I don't like the strict rule that model is not allowed to access logic - how I'm supposed to create "intelligent" objects in the model if they are not allowed to use advanced stuff from the logic package?

• The file path right now is stored as an absolute path. Is this ok? If not, what should be the "base" of a relative path? The bib file?

---

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)
• If you changed the localization: Did you run gradle localizationUpdate?

[Siedlerchr]

Regarding the File Directory stuff: We have a method: getFirstExistingFileDir which gives you the file directoy (either main file idr, bib file or library setting=

[tobiasdiez]

@Siedlerchr thanks! Do you think it makes sense to apply the same rules for the aux files as for pdf files when it comes to relative paths?

[Siedlerchr]

This equals method looks weird. Why not use instanceof?

[tobiasdiez]

Because I don't want subgroups to be considered equal to this class?
(The equals method is, by the way, mostly auto-generated by intellj

[lenhard]

The architecture is not set in stone, we can always decide to change it. Having said that, I still think that the current separation of model and logic makes sense and I think that the tests are useful. Through the tests, we always get a notification about changes that easily turn into circular dependencies and we have an opportunity to discuss them. If we don't have that, then the code will just silently turn into a big ball of mud with circular dependencies everywhere.

Looking at the code, I don't really see an architectural problem. Right now, you are computing the Set<String> keysUsedInAux on demand in a call to contains(). You can just do that when you create the group and pass the set into the constructor, dependency problem solved.

When you want to recognize changes in the aux file, you will need to monitor the file (which is functionality that is located in the higher layers anyway). Then, you could add a setter to the group that resets the keys when a file change happens.

[tobiasdiez]

@lenhard I now used your approach: the TeX group class only relies on interfaces (defined in model), while the concrete implementation of these interfaces resides in logic.

This PR is now ready-for-review. We should really consider using a dependency injection framework...most of the line changes are just propagating the file monitor from Globals to the TeX group.

[lenhard]

@tobiasdiez Yes, applying a dependency injection framework might help to simplify the code. But even if we apply one, we're still going to need interfaces and we'll have to stay clear of circular dependencies. If anything, this problem is going to get bigger with our move to Java 9. With jigsaw, Java will no longer compile the code if there are circular dependencies between modules (if I recall everything correctly).

Apart from that, you're still having some dependency issues here that need fixing ;-)

[lenhard]

Since the FileUpdateMonitor interface is in model, why don't you just put this class into the exact same package? It would solve the dependency problems that are still breaking the build.

[tobiasdiez]

Good observation! I moved the file and so fixed the build.

[lenhard]

I have tested this locally now and it works for me.

This is good to be merged in my point of view.

[tobiasdiez]

In order to somewhat keep the momentum up and reduce the number of open PRs, I'll merge this now.