Clarify the contract of features and capabilities

[mkouba]

• introduce enums for core extensions
• validate duplicate features

This PR breaks compatibility:

• string constants from Capabilities and FeatureBuildItem are extracted into enum values; i.e. the FeatureBuildItem.AGROAL is now available as Feature.AGROAL.getName() (and the name is generated from the enum name).
• the names of capabilities were unified and follow the naming conventions for Java packages; i.e. io.quarkus.container-image-s2i is now io.quarkus.container.image.s2i

[kenfinnigan]

One comment is whether it should also update the documentation at https://quarkus.io/guides/building-my-first-extension#deploying-the-greeting-feature and https://quarkus.io/guides/writing-extensions#sample-test-extension to explain features and capability differences

[mkouba]

@kenfinnigan That's a very good point. I'll update those docs tomorrow.

[geoand]

I might have missed something since I am on PTO today, but what motivated this?

[mkouba]

I might have missed something since I am on PTO today, but what motivated this?

There was a discussion around features and capabilities here: https://groups.google.com/forum/#!topic/quarkus-dev/QnGTnXIEAW8 (first part of the thread)

So I've tried to clarify the contract and refactor some bits, because the string constants are error-prone (even now there are inconsistencies like io.quarkus.resteasy-mutiny vs io.quarkus.elytron.security.ldap).

@geoand Do you think it's useless (or too much ;-)?

[geoand]

@geoand Do you think it's useless (or too much ;-)?

Not at all, I just wanted to know what promted it :)

[geoand]

One rather serious implication is that this might break 3rd party extensions out there, potentially making releasing version 1.6 of the platform kind of hard.
So I'll leave it up to @gsmet to decide.

[mkouba]

One rather serious implication is that this might break 3rd party extensions out there, potentially making releasing version 1.6 of the platform kind of hard.

Yeah, I know. The 3rd party extensions that use the capabilities constants would break as I mentioned in the description. Here's the point - we should either do it now or never. And I tend to prefer the first option ;-).

[geoand]

Yeah, I agree with you, it's now or never. But since it could impact the release 1.6 a lot, I see this as being as something in which @gsmet should have the final say.

[mkouba]

@geoand I've reintroduced but deprecated the capabilities constants. This should help a little.

[geoand]

Indeed, that should go a long way, thanks!

+1 from me

[mkouba]

@kenfinnigan docs updated...

[gsmet]

Looks good from a quick glance. Thanks for having the old constants back, that was necessary.

Let's wait for CI and merge.