xml invalid atom statement

[mrwerdo]

Hi there,

The swordv2 interface returns invalid XML because this constructor is called incorrectly.

<http://purl.org/net/sword/terms/depositedOn xmlns="">2025-02-11T05:22:41</http://purl.org/net/sword/terms/depositedOn>

compared with

<depositedOn xmlns="http://purl.org/net/sword/terms/">2025-02-11T23:34:44</depositedOn>

I don't know how to reproduce this short of calling it from DSpace, which is the product I'm using. Please see this issue.

[pdurbin]

Hmm, I see in DSpace you use statement.setOriginalDeposits (which will end up hitting the constructor you mentioned): https://github.com/DSpace/DSpace/blob/19aa8bcce946e8cfcd4ea963cab386d1460f2593/dspace-swordv2/src/main/java/org/dspace/sword2/GenericStatementDisseminator.java#L50

From a quick look at our code, we don't seem to use this "original deposits" functionality in Dataverse. I'm not even sure what it's for. I also poked around with out tests at https://github.com/IQSS/dataverse/blob/v6.5/src/test/java/edu/harvard/iq/dataverse/api/SwordIT.java and I'm getting valid XML.

We forked this library from https://github.com/swordapp/JavaServer2.0 and don't know all the functionality.

You are very welcome to create a pull request.

[mrwerdo]

Right, so I've just created a pull request for this. I suspect it's a change that occurred with updating some dependencies. If you think it'd be valuable, then I can figure out which ones. Otherwise, I've tested it on my instance and the change seems minimally invasive (the constructor call should already exist on previous versions too.)

Thanks for considering the pull request and for keeping the issue open.

I do have a question about your packaging timeline, once the pull request is approved, how and when does this change end up in your published package on maven?