Updated master to 1.5.0-SNAPSHOT and added japicmp-maven-plugin

[Brian Demers <bd...@apache.org>]

I just added the japicmp plugin (under a `ci` profile)
I've been using this plugin in a few other projects, it has it's own
quarks, version compatibility is pretty complicated when you start thinking
about source vs binary compatibly. This on top of what you typically expect
from semver.

Where things start getting interesting is when you add default methods
(from a japicmp github issue)
https://github.com/siom79/japicmp/issues/201#issuecomment-372437436:

Which basically states because of this:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6

> Adding a default method, or changing a method from abstract to default,
does not break compatibility with pre-existing binaries, but may cause an
IncompatibleClassChangeError if a pre-existing binary attempts to invoke
the method. This error occurs if the qualifying type, T, is a subtype of
two interfaces, I and J, where both I and J declare a default method with
the same signature and result, and neither I nor J is a subinterface of the
other.

japicmp treats them as a breaking change, to work around this in other
projects we can do something like this (if/when needed):
https://github.com/okta/okta-sdk-java/blob/master/src/japicmp/postAnalysisScript.groovy#L31-L38


I've also updated our master and PR CI builds to use the `ci` profile. We
can also start adding/moving other static analysis to this profile to speed
up the build (if needed)

Re: Updated master to 1.5.0-SNAPSHOT and added japicmp-maven-plugin

[Francois Papon <fr...@openobject.fr>]

Great!

Thanks Brian ;)

regards,

François Papon
fpapon@apache.org

Le 06/05/2019 à 18:58, Brian Demers a écrit :
> I just added the japicmp plugin (under a `ci` profile)
> I've been using this plugin in a few other projects, it has it's own
> quarks, version compatibility is pretty complicated when you start thinking
> about source vs binary compatibly. This on top of what you typically expect
> from semver.
>
> Where things start getting interesting is when you add default methods
> (from a japicmp github issue)
> https://github.com/siom79/japicmp/issues/201#issuecomment-372437436:
>
> Which basically states because of this:
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.5.6
>
>> Adding a default method, or changing a method from abstract to default,
> does not break compatibility with pre-existing binaries, but may cause an
> IncompatibleClassChangeError if a pre-existing binary attempts to invoke
> the method. This error occurs if the qualifying type, T, is a subtype of
> two interfaces, I and J, where both I and J declare a default method with
> the same signature and result, and neither I nor J is a subinterface of the
> other.
>
> japicmp treats them as a breaking change, to work around this in other
> projects we can do something like this (if/when needed):
> https://github.com/okta/okta-sdk-java/blob/master/src/japicmp/postAnalysisScript.groovy#L31-L38
>
>
> I've also updated our master and PR CI builds to use the `ci` profile. We
> can also start adding/moving other static analysis to this profile to speed
> up the build (if needed)
>