As a developer I don't want outages of http://maven.geotoolkit.org to prevent me from compiling a war file

[pdurbin]

As noted in a variety of places...

• spinning up branches: phase 1 #4990 (comment)
• Running integration tests for more than just API #5068 (comment)
• http://irclog.iq.harvard.edu/dataverse/2018-11-14#i_78721

... our dependency on http://maven.geotoolkit.org being up causes considerable frustration when jar files aren't already cached in ~/.m2 such as when we spin up arbitrary branches on AWS, run Travis builds, set up new developers, etc.

This dependency was added in 64aa054 and is still used in generateImageThumbnailFromInputStream for example: https://github.com/IQSS/dataverse/blob/v4.9.4/src/main/java/edu/harvard/iq/dataverse/dataaccess/ImageThumbConverter.java#L330

Here's how the failure looks at https://travis-ci.org/IQSS/dataverse/builds/455025056 for example:

[ERROR] Failed to execute goal on project dataverse: Could not resolve dependencies for project edu.harvard.iq:dataverse:war:4.9.4: Failed to collect dependencies at javax.media:jai_imageio:jar:1.1.1: Failed to read artifact descriptor for javax.media:jai_imageio:jar:1.1.1: Could not transfer artifact javax.media:jai_imageio:pom:1.1.1 from/to geotk-repo (http://maven.geotoolkit.org): Failed to transfer file: http://maven.geotoolkit.org/javax/media/jai_imageio/1.1.1/jai_imageio-1.1.1.pom. Return code is: 502 , ReasonPhrase:Bad Gateway. -> [Help 1]

[matthew-a-dunlap]

There are two options to fix this immediately. We can either store this in our local_lib or find a new repo to point towards. The downside with local_lib is it'll increase our app size by ~3mb. I'm looking into a different repo currently.

[matthew-a-dunlap]

Regardless of which option we take, we should probably look for a different library to rely on for the small amount of use we have for these jai_ libraries. Maybe something already imported.

[matthew-a-dunlap]

Ignore my previous comment, this library is still being maintained as a github project, has been updated and is in maven central. I've updated our build to use the latest version and have tested it on thumbnails.

During this research I learned that the repository order in pom.xml alters which one maven looks to first. I've updated our to look to the maven central repo first (instead of primeface's which has almost nothing), hopefully this will speed up fresh builds / travis / aws-autodeploy .