JENKINS-57844 Fix the backward compatibility.

[Smasherr]

Method readResolve() is called by XStream after deserialization to set cacheLocationStrategy..

https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility

[nfalco79]

Merged manually adding a test case

[daniel-beck]

Visibility would ideally be private, because nobody is supposed to call this programmatically outside deserialization. If nobody has a dependency on your plugin doesn't matter, but might otherwise.

[nfalco79]

In the linked documentation all examples reports protected visibility

[daniel-beck]

It's not wrong, but you're not going to have a good time when someone (for some insane reason) starts relying on it and want to retain compatibility. Unlikely, but OTOH it's a trivial change.

[nfalco79]

I will change to private.
If I remember right at the time of adding support for the config-file-provider-plugin I had read somewhere that to differentiate what is APIs from a plugin and what is not the package must contains lib. Similar to the jelly custom libraries

[daniel-beck]

I had read somewhere that to differentiate what is APIs from a plugin and what is not the package must contains lib. Similar to the jelly custom libraries

I have never seen this convention applied in Jenkins plugins.

https://javadoc.jenkins.io/plugin/branch-api/ doesn't. https://javadoc.jenkins.io/plugin/credentials/ doesn't.

https://javadoc.jenkins.io/plugin/scm-api/ has it to some extent (as api/impl), but it appears to be an outlier.

[jikl2001]

I have the 1.3.1 update for the NodeJS plugin, and I noticed that the "Cache location" value for all jobs using the plugin keep reverting back from "Local to the workspace" to the Default value after restarting Jenkins. It looked like it might be related to this issue, so I'm posting here rather than opening a new issue.

EDIT: Actually, since this PR is closed, I'm just going to create a new issue.