fix build and NPE on master

[line-o]

Description:

This PR is deliberately targeting the master branch and does two things:

1. it fixes the build of exist-db #4911
2. it fixes the NPE when an XML-resource is defragmented #5273

Reference:

Backport of #5276 fixes #4911 fixes #5273

Type of tests:

One jUnit test was added that forces defragmentation of a resource on first update to check if the process finishes and the update went through.

[dizzzz]

The NPE I agree on.... that is a bug-fix for the app; The other is a build fix?

[line-o]

The only alternative that I see is that we create a release branch: release-6.2.1

[adamretter]

please could you then indicate how this should be done?

@dizzzz Sure, it's in the documentation - https://github.com/eXist-db/exist/blob/develop/exist-versioning-release.md#release-process

We have no idea what is acceptable for you...

I find that a bit of a strange and jarring comment... This is not at all about what is acceptable to me, it is about following the rules that we all reviewed, agreed to, and documented during an open community process. Those rules were created to make sure that we have a consistent, working, and repeatable process for doing the releases.

I recall that before we documented the process very few people knew how to do a release, doing so was very time consuming and difficult, and each one looked a bit different to the previous one.

This release process document has been in place since 2017 (or earlier?) and every release has followed those instructions since (https://github.com/eXist-db/exist/commits/develop/exist-versioning-release.md).

[adamretter]

The only alternative that I see is that we create a release branch: release-6.2.1

If you follow the documented release process you should not need to create a release branch, you can just tag the appropriate commit.

[line-o]

We need to get a patch release out to fix a fatal regression resulting in data loss. We cannot release from develop-6.x.x (6.3.0-SNAPSHOT) nor develop (7.0.0-SNAPSHOT) because both have too many changes already merged into them. I need to know what the accepted way forward is to be able to release 6.2.1 as the next stable release.

[dizzzz]

@adamretter

I find that a bit of a strange and jarring comment...

That was not my intention, apologies, but clearly we (me) need some (more) guidance and would like to fix some long-time issues.

[line-o]

@adamretter the document you refer to only mentions the develop branch which is not suitable to create a 6.2.1 as it contains a snapshot of version 7 and contains breaking changes. There is no mention of the development branches for earlier versions. But as I already wrote develop-6.x.x does already contain quite a few changes and might therefore not be suitable either. @dizzzz I will keep this open until we decided how to create a patch release