Predatory journal checker

[xuanan20020]

Continue to resolve koppor#348

The implementation attempts to match the architecture of the JournalInAbbreviationListChecker.

This draft pull request will be updated as the implementation is completed.

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.

[xuanan20020]

Thanks for the comments! I will get those issues resolved

[xuanan20020]

Sorry, I didn't follow the background thread approach since generating an MV file for predatory journals in the JournalListMvGenerator makes more sense to me, although that abuses the purpose of that class a little. But with this, I just have to update the file once and all subsequent loadrepository() call does not require any update from the web. Also, it was really difficult to get the BackgroundTask Wrapper to work on the update method without failing the MainArchitectureTest

[Siedlerchr]

Okay, I will try to find a way to integrate this into a BackgroundTask.

[Siedlerchr]

Sorry about that BackgroundTask stuff. I did not know the task is only executed when you run the journal list generation gradle task.

We still need to have an option to update this, but I think this is for future use. currently it will be updated only at build time

[Siedlerchr]

I am okay with this now. It will be updated along when our github workflow runs. So no need to threading handling

[xuanan20020]

Thanks for reviewing the code :D. It was @koppor 's suggestion to have the MV file generated in such a manner. He recommended under the issue.

[koppor]

I went through the code and have detail comments.

But one general one, which I was not able to fully write the new code.

The core idea is that PredatoryJournalRepository contains the data. ALL code uses that repo. - The repository is filled by the PredatoryJournalLoader. This is called by PredatoryJournalListMvGenerator. And NOWHERE else!

PredatoryJournalListMvGenerator is a new class with a main method similar to JournalListMvGenerator. Reason: Separation of concerns. Generating a journal abbrevation list is completely different from the predatory list generation. Thus, different main applications.

In other words:

• PredatoryJournalRepository loads the .mv file.
• PredatoryJournalLoader is only used ONCE in PredatoryJournalListMvGenerator. No other usages. Not in IntegrityChecks etc... They get their data from the PredatoryJournalRepository

Please hook PredatoryJournalListMvGenerator into the build process as described there:

jabref/build.gradle

Line 319 in 0a6f647

tasks.register("generateJournalListMV", JavaExec) {

[linsui]

Hi, when I update the jabref package for nixos I found that I can't generate the list in an offline sandbox. And it's hard to make the list reproducible because it fetches data from webpages. Any suggestion what I should do?

[koppor]

@linsui Are you a programmer or "just" a package creator?

If a programmer: We need to work together to modify the feature. See discussion at https://discourse.jabref.org/t/double-check-the-bibliography-for-predatory-publishers-and-journals/1738/7.

If a package creator: Maybe, it is possible to mock a HTTP server containing some data?

Maybe a quick fix can be to just return an empty list in case of a connection error?

[linsui]

Hi, I'm just a package maintainer and I don't know much about java programming. :)

Maybe a quick fix can be to just return an empty list in case of a connection error?

Good idea. :)