fix: QName constructor calls

[mrwerdo]

This fixes issue #190. A dependency updated which changed the default behaviour of a constructor call. This fixes it so that it calls the constructor correctly (which it's already doing in the same file.)

Where should the reviewer @DANS-KNAW/easy start?

I'd recommend checking that your systems don't break with the change, though I consider this unlikely. If you prefer, we could talk about automated testing...

How should this be manually tested?

Test this in DSpace by submitting a package to DSpace using the sword endpoint. See the original issue. I've been able to test this and verify that the changes work my institution's instance of DSpace.

[poikilotherm]

I am currently updating the Maven Parent at https://github.com/gdcc/maven-parent to re-enable publishing new versions of this. It will require some adaptions first.

Once that is squared away, I will update this PR. IMO we should restructure the UriRegistry to be an enum with a namespace and the term. Using toString() and toQName() then should allow to avoid duplication and better usage.

[pdurbin]

@mrwerdo thanks for this PR and the discussion in the issue (#190). I hate to say it but now that we've realized that this SWORD library (which we forked and maintain) depends on a package that's in the Apache Attic (Abdera), it's making us wonder if we should deprecate the entire SWORD API in Dataverse. Our first step would probably be to see how much usage SWORD has, at least in Harvard Dataverse (one of many installations around the world):

• Assess local and Community use of Dataverse APIs IQSS/dataverse-pm#424

That is to say, please don't expect us to review or QA this any time soon. Thanks!

By the way, yes, we are getting publishing to Maven Central working again:

• the way we publish to Maven Central (OSSRH) is reaching end of life on June 30, 2025 IQSS/dataverse#11512

[mrwerdo]

@pdurbin No worries, I appreciate the update.