We don't need to print the Handle because some items can be in the
workflow still so this will be null, but also because DSpace will
already show the Handle in the log before printing the result.
Results are a single-line status that shows the result of the task,
but reports are like a running log of changes to the item and have
more complicated use cases and configuration requirements.
For now I will disable reports since I'm not using them.
New as of JDK 9:
> The --release option ensures that the code is compiled following the rules of the programming language of the specified release, and that generated classes target the release as well as the public API of that release. This means that, unlike the -source and -target options, the compiler will detect and generate an error when using APIs that don't exist in previous releases of Java SE.
Also, as of DSpace 7 we the minimum JDK is 11 anyway.
See: https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html
It seems Handle jars are not published on Maven Central so we get
this error while packaging:
[ERROR] Failed to execute goal on project cgspace-java-helpers: Could not resolve dependencies for project io.github.ilri.cgspace:cgspace-java-helpers:jar:7.6-SNAPSHOT: net.handle:handle:jar:9.3.0 was not found in https://repo.maven.apache.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
This is probably related to DSpace 7.x using a vanilla Handle jar
instead of the customized one.
I was wondering why the same bitstreams appeared to be getting de-
leted on every single run. It turns out that the only mode we were
committing the context in was in single item mode. If the argument
was a site, community, or collection we were updating the item but
not actually committing the changes!
Alan Orth