Introduce a mechanism to know whether it supports native or not

[gastaldi]

With Quarkiverse, many extensions may not support Native (right away) so it would be nice to have some mechanism in place to flag in the extension metadata

[cescoffier]

Some extensions have partial support for native. Would the flag mean 100% support, or do we need a 3 value flag (so not a flag):

• supported
• partially supported
• unsupported

[gastaldi]

I think it would be nice to also have a description of what's partially supported in this case

[jtama]

Could it be part of the quarkus-extension.yaml, just like the status is ?

[gastaldi]

Could it be part of the quarkus-extension.yaml, just like the status is ?

Sure, I think it should be part of the metadata entry in that YAML file

[maxandersen]

@cescoffier having partial support notion could be useful i think but what are the current examples we are aware of that is "partial" ? is it like "sometimes it works" or "user has to do something to see it work/fail" ?

[cescoffier]

We had partial support in the past, but I fixed them recently (Avro, Snappy). So, I don't have more examples from my side. However, having a dependency having some kind of support but part of the API unsupported won't be rare.

UPDATE: MP Fault tolerance fallback unsupported in native is kind of a "partially supported".

I want to also note, that some extension works only on the very last GraalVM (serialization, method handle...).

[gastaldi]

Perhaps we could have a reason metadata property (name yet to be defined) explaining why the extension doesn't work in native (possibly pointing to a URL with more info)

[ppalaga]

We (Camel Quarkus) document the limitations on our extension pages. Here is an example: https://camel.apache.org/camel-quarkus/latest/reference/extensions/activemq.html#_camel_quarkus_limitations So we would not mind having a markup for the situation when there are limitations known for the given extension.

[Karm]

@gastaldi

There is this UnsupportedOSBuildItem.java used e.g. as

    @BuildStep(onlyIf = NativeBuild.class)
    UnsupportedOSBuildItem osSupportCheck() {
        return new UnsupportedOSBuildItem(WINDOWS,
                "Windows AWT integration is not ready in native-image and would result in " +
                        "java.lang.UnsatisfiedLinkError: no awt in java.library.path.");
    }

Perhaps it could be enhanced to allow for a warning instead of the hard termination of the native build process it does now.

[gastaldi]

@Karm not sure about that. This build item is meant to fail the build because the app won't work in a specific OS, due to GraalVM or OS limitations

[fedinskiy]

@gastaldi this issue had not activity for three years. Is it still something, that is being considered?

[gastaldi]

@fedinskiy I don't think it had much traction, given the lack of activity for so long. I believe an acceptable solution is what @ppalaga suggested in https://github.com/quarkusio/quarkus/issues/12607#issuecomment-810059036 (documenting it properly).

Any ideas?