New Features proposal.

[tomas-langer]

Features are now an annotation on a module (see config and webservers).

When you run MP with this setup (WebServer is configured NOT to be in MP, there is not a single MP module):

Helidon MP 4.0.0-SNAPSHOT has no registered features
io.helidon.common.features.HelidonFeatures features - Invalid modules are used:
        Module "io.helidon.reactive.webserver" (WebServer) is not designed for Helidon MP, it should only be used in Helidon [SE]

When you run SE with this setup:

Helidon SE 4.0.0-SNAPSHOT features: [Config, WebServer]

Example of generated file for webserver. Names are shortened to reduce size (not for user interaction) (META-INF/helidon/native-image/reflection-config.json):

m=io.helidon.reactive.webserver
n=WebServer
d=Reactive Web Server
in=SE
not=NIMA,MP

module, name, description, in, not-in

TODO:

• move all features that are in old catalogue to annotations (and add in/not-in as required)

[tjquinno]

Do we need both "in" and "not in" for this? I would think that either

• one can be derived or inferred from the other, or
• the names do not exactly represent what those values truly mean.

Having both also would allow someone (us!) to incorrectly specify the same flavor in both which implies that some code somewhere should validate the two settings and report improper combinations.

It seems simpler and easier to have just "in."

What am I missing?

[tomas-langer]

IN - means this feature will be reported in this flavor (such as Config will be reported in Níma and SE, but will not be reported in MP, as that is done by MP Config) NOT-INF - means this feature is "forbidden" in that flavor (such as reactive webserver once MP is based on Níma)

[tjquinno]

I see.

I know we prefer short names, but if that means "forbidden" maybe we should call it that or "excluded" or something else instead of "not in" to avoid the confusion?

[trentjeff]

I like this proposal. My only hope is we can also capture a concept of trait here as well. For instance, I would like a trait that represents whether a module supports native, or is free of reflection, etc. Any chance we can have profile overloaded to handle the trait concept also? If not then I think we should also add Trait to this proposal as well.

[tomas-langer]

There is @Aot annotation as part of this PR which you can use to mark a component as not supporting native (or add description to be warned when building such a component with native image). There is also @Experimental (which we may rename) to be used with experimental (incubating?) features. I did not plan to have any general type annotation for "a trait" - it is all quite explicit, as it has explicit usage during startup or during native image build.

[romain-grecourt]

LGTM.

[tomas-langer]

Closing this PR, there is a new branch to continue on: https://github.com/helidon-io/helidon/tree/4.x-features