Make the plugin JCasC compliant

[Wadeck]

The problems were:

• Some getters were not following basic POJO rules
• The PostConstruct on private method is supported by the JavaDoc of the annotation but not yet by JCasC

The first point resulted in the plugin not being fully configurable and the second one to crash the instance once setup.

@daniel-beck @ewelinawilkosz

[jeffret-b]

Changes look fine and look like they should correct the problem. I haven't tested it out but I could do that if requested.

[daniel-beck]

Looking over it, this looks reasonable. The renames seem a bit unnecessary, but if it reads better in JCasC YAML…

Ideally we'd get someone from JCasC to confirm this variant is better, and the setup problem is addressed.

[oleg-nenashev]

Looks good, thanks! Would be nice to have a JIRA issue so that it is listed on the compatibility dashboard

[Wadeck]

The renames seem a bit unnecessary

An attribute is "valid" for JCasC only if it has a field and a valid related getter, it was not the case due to the "ing" I added for some names :'(

Ideally we'd get someone from JCasC to confirm this variant is better, and the setup problem is addressed.

Anyone can test it with JCasC plugin, no need to be an expert actually.

But I totally agree we need at least one manual test to ensure it's working (in additon to mine), as we have 3 "look", they are not sufficient ;)

@oleg-nenashev => https://issues.jenkins-ci.org/browse/JENKINS-60523 with jcasc-compabitility label, not sure if you need something else in the ticket ;)

[oleg-nenashev]

Good enough, thanks

…

On Wed, Dec 18, 2019, 11:58 Wadeck Follonier ***@***.***> wrote: The renames seem a bit unnecessary An attribute is "valid" for JCasC only if it has a field and a valid related getter, it was not the case due to the "ing" I added for some names :'( Ideally we'd get someone from JCasC to confirm this variant is better, and the setup problem is addressed. Anyone can test it with JCasC plugin, no need to be an expert actually. But I totally agree we need at least one manual test to ensure it's working (in additon to mine), as we have 3 "look", they are not sufficient ;) @oleg-nenashev <https://github.com/oleg-nenashev> => https://issues.jenkins-ci.org/browse/JENKINS-60523 with jcasc-compabitility label, not sure if you need something else in the ticket ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAW4RIAV4GMVGJ3E4PAFNQDQZHQ2VA5CNFSM4J34W5S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHFM7EI#issuecomment-566939537>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW4RIDADZ54RJXOQJR6HR3QZHQ2VANCNFSM4J34W5SQ> .

[ewelinawilkosz]

wanted to try but building make-compatible-with-jcasc branch (mvn install) fails for me:

[INFO] --- spotbugs-maven-plugin:3.1.11:check (spotbugs) @ strict-crumb-issuer ---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
[ERROR] StrictCrumbIssuer.md not guarded against concurrent access; locked 75% of time [org.jenkinsci.plugins.strictcrumbissuer.StrictCrumbIssuer, org.jenkinsci.plugins.strictcrumbissuer.StrictCrumbIssuer, org.jenkinsci.plugins.strictcrumbissuer.StrictCrumbIssuer, org.jenkinsci.plugins.strictcrumbissuer.StrictCrumbIssuer] Unsynchronized access at StrictCrumbIssuer.java:[line 191]Synchronized access at StrictCrumbIssuer.java:[line 276]Synchronized access at StrictCrumbIssuer.java:[line 440]Synchronized access at StrictCrumbIssuer.java:[line 441] IS_FIELD_NOT_GUARDED

Any idea what am I doing wrong? :)

[Wadeck]

@ewelinawilkosz I just added the Jenkinsfile in this PR and it was failing for the same reason. I changed the code :)

[ewelinawilkosz]

Nice! That was fast :) I mean solving the whole compatibility issue. Thanks!
I managed to build and verify the behavior, works well

[jetersen]

belated LGTM