Introduces test http server

[koppor]

As a present for 🥚🐇 - first working Word-JabRef integration. Come out as preparation for a http-based client/server sync, some "small" http server offering an endpoint to JabRef Word Add-In.

---

To get the Word Plugin run:

• Add SSL certificate to JabRef https://github.com/JabRef/JabRef-Word-Addin/pull/568/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5
• Start TestServer in JabRef
• Usual node, yarn install things

---

• This closes Add HTTP server for MS Office Word integration #9246, because this implementation is complete.
• This closes WIP Restapi koppor/jabref#628, because this implementation transfers all BibTeX data to the client (and not only selected fields). Moreover, this PR generates data directly processible by CSL proc (based on the already existing implementation)

---

In IntelliJ Ultimate (not community), you can open rest-api.http and play around there. Start main in TestServer to get the server running.

You can go to LibraryResourceTest to execute some tests (server is started automatically)

---

Changes in the code:

• Add resources
  • /libraries
  • /libraries/{id} (both (embedded) BibTeX as string and CSL data)
• Documentation / code style
  • Refined BibEntry class (JavaDoc, builder)
  • Comments to InternalField
  • move StyleTester to "test" module - package ...testutils/interactive...
• Makes use of Jersey, Grizzly
• Makes use of HK2 as dependency injection framework
• Introduces "application/x-bibtex-library-csl+json" mimetype
• Preparation for client/server sync (BibEntryDTO)
• Minor
  • Made class "JabRefItemDataProvider" more visible
  • Encoding of a .bib file can now be asked for externally
  • Resorts modle-info.java
  • Fixes typo in NetworkTabViewModel
• Installs SLF4J logging router: If a tool uses java commons logging, tinylog now also handles these logs

---

Future work (in a follow-up PR)

In a next PR, I am going work on a minimal implementation for #9220.

---

Compulsory checks

Beta Give feedback

1. Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
2. Tests created for changes (if applicable)
3. Manually tested changed features in running JabRef (always required)
4. Screenshots added in PR description (for UI changes)
5. Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
6. 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.

[HoussemNasri]

Great! I didn't know about Word add-in; it is much better than exporting XML references. I wonder if #6904 is still relevant anymore? I was hoping I could get to it this summer but as the integration with the Word addin progresses, I think I'm going to select another project.

[Siedlerchr]

Method too large

[koppor]

Method too large

I know. We made some progress in the jdk fix: openjdk/jdk#10704 (comment)

[Siedlerchr]

Do we really need this jul adapter?

[koppor]

Yes. The Grizzly http server uses java-util-logging. To be able to handle the log output with our logging framework tinylog, we need jul-slf4j-tinylog.

More detailed:

• We opted for SLF4J as the JabRef logging framework. We decided against direct calls to tinylog.
• For log output of an application, there should be one logging framework
• When using the http server, JabRef internal methods are used. They might log. Thus, we have logs using of SLF4J
• Grizzly uses Java-Util-Logging - and outputs are produced.

The alternative can be to disable logging of Grizzly completely and bring it back (with the bridge) if needed.

[koppor]

Update: Test files can be passed to the server. Adds a default serving file (so that developers not familiar with JabRef can just start the server)

I started to enable starting the server using gradle:

./gradlew run -Papplication=httpserver

However, I have issues with ForkJoin (discussion at https://discuss.gradle.org/t/is-it-ok-to-use-collection-parallelstream-or-other-potentially-multi-threaded-code-within-gradle-plugin-code/28003)

Gradle output:

> Task :run
2023-04-20 11:30:59 [main] org.jabref.http.server.Server.main()
DEBUG: Libraries served: [C:\git-repositories\jabref-all\jabref\src\main\resources\org\jabref\http\server\http-server-demo.bib]
2023-04-20 11:30:59 [main] org.jabref.http.server.Server.startServer()
DEBUG: Starting server...
<============-> 92% EXECUTING [2m 27s]
> :run

IntelliJ output, if org.jabref.http.server.Server#main is executed:

DEBUG: Starting server...
2023-04-20 11:44:59 [ForkJoinPool.commonPool-worker-1] org.glassfish.grizzly.http.server.NetworkListener.start()
INFO: Started listener bound to [localhost:6051]
2023-04-20 11:44:59 [ForkJoinPool.commonPool-worker-1] org.glassfish.grizzly.http.server.HttpServer.start()
INFO: [HttpServer] Started.
2023-04-20 11:44:59 [ForkJoinPool.commonPool-worker-1] org.jabref.http.server.Server.lambda$startServer$4()
DEBUG: Server started.

[koppor]

The commit 1c50d78 should be "intelligently" reverted to keep things going here.

[github-actions]

Your code currently does not meet JabRef's code guidelines. The tool reviewdog already placed comments on GitHub to indicate the places. See the tab "Files" in you PR. Please carefully follow the setup guide for the codestyle. Afterwards, please run checkstyle locally and fix the issues.

More information on code quality in JabRef is available at https://devdocs.jabref.org/getting-into-the-code/development-strategy.html.

[github-actions]

The build for this PR is no longer available. Please visit https://builds.jabref.org/main/ for the latest build.