libs.fabric8: Prevent generation of signature files and fix description

[matthiasblaesing]

No description provided.

[mbien]

thanks for fixing this

[jhorvath]

Looks good. Thanks for fixing it.

[neilcsmith-net]

Thanks for fixing.

Given your comment about sigtests and version, possibly consider adding the library version as the module implementation version like we do elsewhere too?

[matthiasblaesing]

@jhorvath @neilcsmith-net @mbien thank you all for review!

@neilcsmith-net using the library version as module version is indeed an option, but it will still need active checking from the updater. The spec version and the major module version are not linked. Nothing is stopping you from going from org.netbeans.libs.fabric8/1 with spec version 1.11 to org.netbeans.libs.fabric8/1 with spec version 2.0, while you most probably wanted to go to org.netbeans.libs.fabric8/2 with spec version 2.0. Only the second variant indicates an incompatible update as in "the IDE prevents linking" (at least to my understanding).

I would expect such a high profile module to follow semantic versioning, but that would need checking. Another think is preventing bump of spec version in release, else the versions will drift again.

At this point in time I think it is better to focus on the freeze.

[neilcsmith-net]

@matthiasblaesing absolutely, doesn't provide any additional protection, just a little extra info.

@jhorvath if you update these libs in future, please consider mapping the upstream version to implementation version, as with a few other recent third party additions.

[mbien]

one thing we should do at some point is to switch to jdk equivalents
https://github.com/matthiasblaesing/netbeans/blob/e09743956d580fa65411594acb197b02c3eba802/enterprise/libs.fabric8/external/binaries-list#L41-L45
kubernetes-httpclient-jdk is available for example. I think this would be even possible before freeze as long its manually tested.

this was also mentioned under the original PR