[SOLVED] Maven deploy fails with status 422 unprocessable entity

It has been more than a year since I created this question on GitHub Community; a couple of days after that I found the solution by myself, so I answered my own question, and to this date comments keep being added by people who were helped by my post.  

When I look at it today, I notice that my answer has this particular style, this grumpy indignation which has become so characteristic of me, after a lifetime of battling with lame software, and even worse, with lame error messages. 

I thought I should share this on my blog for posterity.

Here is the link:

Intertwine

Abstract

A mechanism is described for automatically converting method invocations of any programmatic interface into a single-method normal form and converting back to invocations of the original interface, so that general-purpose operations can be performed on the normal form without explicit knowledge of the interface being invoked. Implementations are provided for C# and for Java.

Bathyscaphe

The Bathyscaphe logo, a line drawing of bathyscaphe Trieste

by Mike Nakis, based on art found at bertrandpiccard.com

Abstract

This article introduces Bathyscaphe, an open-source java library that you can use to assert that your objects are immutable and/or thread-safe.

The problem

Programmers all over the world are embracing immutability more and more; however, mutation is still a thing, and in all likelihood will continue being a thing for as long as there will be programmers. In a world where both mutable and immutable objects exist side by side, there is often a need to ascertain that an object is of the immutable variety before proceeding to use it for certain purposes. For example, when an object is used as a key in a hash map, it better be immutable, or else the hash code of the key may change, causing the map to severely malfunction.

Furthermore, when an object is not immutable, there is often the need to ascertain that it is at least thread-safe before sharing it between threads, otherwise there will be race conditions, with catastrophic results.

Note that when any of the above goes wrong, it tends to be a bug which is very difficult to troubleshoot.

Java with Maven: Giving CI/CD a try

Please note that this is work in progress.  I am still working on it and refining it, as my understanding of it improves.

I have a set of public repositories on GitHub showcasing my work, (⬀) which is in java with maven. These projects are interdependent, so when you check out one of them, in order to compile and run it you need the binaries of some of the others. You could manually check out all of them and put them in an IDE project, but that's too much work. Solving this problem requires having Continuous Integration & Continuous Deployment (CI/CD) in place, so I decided to try my luck in setting one up using free services only.

The process involves three entities:

• A Source Repository.  (Where our source code is hosted.)
• I use GitHub for this.
• Possible alternatives:
• GitLab
• BitBucket
• A CI/CD provider. (Where the actual CI/CD takes place.)
• I decided to use CircleCI for this, but in retrospect it was a bad idea, because it does not support GitLab.
• Possible alternatives:
• GitLab - I want to use it as a source code repository, and I don't want to put all my eggs in one basket, so I don't want to use it for anything else.
• GitHub - I want to use it as a source code repository, and I don't want to put all my eggs in one basket, so I don't want to use it for anything else.
• BitBucket - it is by Atlassian. Need I say more.
• Appveyor - gives various errors like "There was an error while trying to complete the current operation. Please contact AppVeyor support." -- Lots of open source projects are using it though, so it might be worth a second try.
• Travis CI - only works with github.
• JFrog - overwhelmingly fancy front page followed by a not particularly fancy user experience once you get past the front page. Once I have registered, there is no way for me to log back in. 
• semaphoreci.com - only works with github.
• buddy.works - after you have given them your e-mail address, they tell you that it is free but they require a valid payment method.
• atlassian.com/software/bamboo - it is by Atlassian, need I say more.
• drone.io - not only it works with nothing other than github, they assume that I am using github, which is very annoying.
• octopus.com - registration fails with "Please use your work email address."
• buildkite.com - might work; not particularly user friendly.
• codefresh.io - might work; they unnecessarily complicate things with mandatory docker images.
• An Artifact Repository. (Where the binaries are stored.)
• I found a place called Repsy for this; Repsy is minimalistic, unrefined, and they even have bad English on their web site, but it will do for now.
• Possible alternatives:
• GitHub Packages
• GitLab Package Registry
• JFrog Artifactory

We begin with a situation where we already have the Source Repository (GitHub) and we want to set-up the CI/CD Provider (CircleCI) and the Artifact Repository (Repsy).

Migrating a project from java 8 to java 9

Now that Java 9 is out, I decided to migrate to it my pet project, which is around 120K lines of java.

The first step is to just start compiling and running against jdk9, without using any of its features yet.

This is an account of the surprisingly few issues that I encountered during this first step and how I resolved them.

Issue #1: Object.finalize() has been deprecated.