"[WARNING] unknown enum constant org.osgi.annotation.bundle.Requirement.Resolution.OPTIONAL" when compiler warnings are enabled #19970
Comments
famod
added
kind/bug
|
You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip.
|
|
/cc @radcortez |
|
Unfortunately, there is nothing we can do on the Quarkus side because this is caused by an issue in the MP Config API. Opened eclipse/microprofile-config#716 to see if we can fix it there. |
radcortez
removed
the
triage/upstream
|
Thanks for looking into it! |
|
Sorry, I've removed it because I thought this is already "triaged" and that we now have a linked issue to the upstream dependency. |
|
Ah ok. I thought we also use it to flag issues that are waiting for upstream changes. 🤷♂️ |
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. To address this, we replace the enum classes with simple classes holding string constants and change the annotation elements returning the enum values to return string values. This is generally source compatible with usage of the OSGi annotations. Since these are CLASS retention annotations, they are not visible at runtime and so only tools, like Bnd, which process the annotations at tool time are affected. Bnd 6.2 is being taught to seamlessly handle old and new annotations using the old enum values or the new string values. So moving to using the updated OSGi annotations will also require moving to use Bnd 6.2 or later. Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
|
FYI, I am working a fix to the OSGi annotations to replace use of enum types with String along with a corresponding fix to Bnd to support this change. |
|
I confirm the |
gsmet
added
the
triage/upstream
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. To address this, we replace the enum classes with simple classes holding string constants and change the annotation elements returning the enum values to return string values. This is generally source compatible with usage of the OSGi annotations. Since these are CLASS retention annotations, they are not visible at runtime and so only tools, like Bnd, which process the annotations at tool time are affected. Bnd will seamlessly handle old and new annotations using the old enum values or the new string values. So moving to using the updated OSGi annotations will not require updating to use a newer version of Bnd. Bnd 6.2 is being updated to better handle these changes including validation of the string values since a string return type is open ended while an enum return type is not. Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. To address this, we support the use of enum values or string values as the annotation element value. This will support the OSGi change in osgi/osgi#404 We seamlessly handle old and new annotations using the old enum values or the new string values. So moving to using the updated OSGi annotations will also require moving to use Bnd with this fix. Signed-off-by: BJ Hargrave <bj@hargrave.dev>
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. We support the use of enum values or string values as the annotation element value through existing conversion support. The OSGi change in osgi/osgi#404 will move from using enum types to use string values which are case-insensitive equivalent to the enum value names. We seamlessly handle old and new annotations using the old enum values or the new string values. Prior to this fix, Bnd already handled the change through a fallback in Converter which uppercased the string value before converting to an internal enum value. This change avoids the internal enum type and processes the string value or string name of the enum value when processing older versions of the OSGi annotations. Signed-off-by: BJ Hargrave <bj@hargrave.dev>
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. To address this, we replace the enum classes with simple classes holding string constants and change the annotation elements returning the enum values to return string values. This is generally source compatible with usage of the OSGi annotations. Since these are CLASS retention annotations, they are not visible at runtime and so only tools, like Bnd, which process the annotations at tool time are affected. Bnd will seamlessly handle old and new annotations using the old enum values or the new string values. So moving to using the updated OSGi annotations will not require updating to use a newer version of Bnd. Bnd 6.2 is being updated to better handle these changes including validation of the string values since a string return type is open ended while an enum return type is not. Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
Using enum types in the CLASS retention bundle annotations is causing issues for those using the annotations. Various tools, such as javadoc, attempt to reify the elements in the annotations and since the osgi.annotation jar is generally a scope=provided dependency, the enum types are not available to downstream users of the jars using the OSGi annotations and so tools generates an annoying warning. See quarkusio/quarkus#19970 and eclipse/microprofile-config#716. We support the use of enum values or string values as the annotation element value through existing conversion support. The OSGi change in osgi/osgi#404 will move from using enum values to use string values which are equivalent to the former enum value names. We seamlessly handle old and new annotations using the old enum values or the new string values. Prior to this fix, Bnd already handled the change through the Converter which converts the string value to an internal enum value. This change avoids the internal enum type and processes the string value or string name of the enum value when processing older versions of the OSGi annotations. Signed-off-by: BJ Hargrave <bj@hargrave.dev>
|
FYI, eclipse/microprofile-config#732 has been filed to update MicroProfile Config API to avoid the compiler warning issue. |
|
Have that too for quite a while now :( |
|
@MarcusBiel 2.7.3 should have fixed this (I haven't checked yet). |
|
I can confirm this is fixed in 2.7.3.Final |
|
Can't confirm since 2.7.3 doesn't work for me: -- |
|
Better open an issue in the respective quarkiverse extension with a small reproducer |
Me too now. |
Describe the bug
maven-compiler-pluginissues a warning when your app is using@ConfigPropertyand compiler warnings are enabled:Expected behavior
No such warning.
Actual behavior
Warning w.r.t OSGI annotations. Also pollutes "real" compilation errors which can lead developers astray.
How to Reproduce?
./mvnw clean compile -f config-quickstart/ -Dmaven.compiler.showWarnings=trueinquarkus-quickstarts.Output of
uname -aorverLinux XXX 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -versionOpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.1.2.Final, probably since 2.0, up to current 999-SNAPSHOT
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.8.1
Additional information
https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/OSGI.20Warnings
https://mvnrepository.com/artifact/org.eclipse.microprofile.config/microprofile-config-api/2.0 defines provided OSGI annotations.
Adding https://mvnrepository.com/artifact/org.osgi/osgi.annotation/7.0.0 works around the issue.
The text was updated successfully, but these errors were encountered: