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!
- Switch to Ubuntu 22.04 because `ubuntu-latest` is still 20.04
- Update actions to latest versions
- Specify Java 8 instead of 1.8
- Enable Maven caching
Instead of checking whether they exist and then skipping them just
at the moment when we want to swap the bitstreams let's bail early
when we know an item is an Infographic or a Map.
This adds another script to detect and remove more low-quality thu-
mbnails. For example:
- If an item has an "IM Thumbnail" and a "Generated Thumbnail" in the
THUMBNAIL bundle, remove the "Generated Thumbnail"
- If an item has a PDF bitstream and a JPEG bitstream with a name or
description "thumbnail" in the ORIGINAL bundle, remove the
"thumbnail" bitstream in the ORIGINAL bundle and try to remove the
"thumbnail.jpg" bitstream in the THUMBNAIL bundle
The idea is that we should *always* prefer thumbnails generated by
ImageMagick from PDFs in the ORIGINAL bundle and should remove any
other manually uploaded thumbnails.
Alan Orth