please fix checkstyle

Please resolve conflicts

Please rebase against master to fix broken Github CI builds!

A function is static if it does not use member variables, and does not use other functions that use member variables. In my opinion, any function to which this applies should then also be labeled as such. Then, as a programmer reading the source code, you know that these characteristics are met for this function. This is just like how we mark constants as final. You don't have to do this, it would work without it, but it says something to the programmer reading the code. I like to do that, also for myself, when I read my own code again years later. I find it clearer. Why does it bother you?

Independent of the "static method" changes I'm unsure if all this changes should belong to the "Kitodo-Docket" module as this module in my understanding is only for creating the dockets and not for general generating pdf files depending on xslt, xml and meta data of the process. Maybe this should be discussed first before the changes are made.

The sole purpose of generating the XML log is to create the docket from it. Previously, there were two places where the XML log was generated (duplicate code), one copy in the core for saving it to the user folder, and another copy in the docket module for creating the docket. These two have now been deduplicated and the code now only exists once.

In addition, due to incomplete copy-paste, the saved XML log was not exactly identical to what was generated in the Docket module, so if you developed an XSLT for a docket for a customer and it ran with the saved XML log, it still didn't work reliably with the docket module. This was very nerve-wracking when the customer wants many adjustments to the docket.xslt.

I think this change makes sense for both reasons, code deduplication and better configurability.

This may be true (I did not validate your statement in any little detail) but and in mind of the current module concept the base (generating the XML log) should then be in a separate module and the current docket module should depend on this new module or if there are only some common logic: the common logic should be in one module and the outputs in two depending modules of this common module.

But I don't know if the current module concept is still valid or not. Maybe this should be discussed but there is no discussion ongoing as no one is participating as everyone has only his/her stuff to do. So @solth should be decide if this changes should all go into the current docket module or not.

Hi @henning-gerhardt: I removed the static modifiers from the static functions. From the point of view of the code review, is the source code consistent with the coding guidelines? If so, I would ask you to mark the pull request as approved.

I think the questions of dividing the functions into modules, and how to proceed at all with the modularization of the source code (there are quite a few more open questions, I think), are important, and you are welcome to open a GitHub discussion for this.

I can review this maybe next week and I'm discussing some in deep details only in my native language.