[MRESOLVER-465] Make room for alternate version scheme

[cstamas]

Since eons Resolver had the "generic" scheme implementing the Version, VersionRange and VersionConstraint API interfaces.

Interesting fact: GenericVersionRange and GenericVersionConstraint are NOT tied in any way to GenericVersion implementation, they are happy with plain Version interface as well, they are truly "generic".

This means, that a scheme needs really only to provide Version implementation (currently in form of GenericVersion) and a "factory" for it (currently in a form of GenericVersionScheme).

Refactor a bit, and make room for alternate Version implementations.

Fact: the change can be done in source and binary compatible way, and is enforced by japicmp.

---

https://issues.apache.org/jira/browse/MRESOLVER-465

[gnodet]

Does it make sense at all ? This isn't a data object. If there's a need, they should be identified by a name imho.

[gnodet]

Useless

[cstamas]

@gnodet agreed with all, but I did not change any of these (all is same as it is in today code, recheck if you want), all I did is split the class (support + generic scheme). The idea is to have new version scheme provided by Resolver in this very same package (not by "third party" as that would open up a can of worms).

[gnodet]

@gnodet agreed with all, but I did not change any of these, all I did is split the class (support + generic scheme). The idea is to have new version scheme provided by Resolver in this very same package (not by "third party" as that would open up a can of worms).

Then VersionSchemeSupport should not be public. That will remove almost all those problems.

[cstamas]

Oh, yes, true, oversight on my part. Fixed

[gnodet]

Oh, yes, true, oversight on my part. Fixed

Much better now. Do we need to keep the hashCode / equals on version scheme ? They really look weird on a pure service class.

[cstamas]

Removed them.