Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"[WARNING] unknown enum constant org.osgi.annotation.bundle.Requirement.Resolution.OPTIONAL" when compiler warnings are enabled #19970

Closed
famod opened this issue Sep 7, 2021 · 15 comments · Fixed by #23870
Assignees
Labels
area/config kind/bug Something isn't working
Milestone

Comments

@famod
Copy link
Member

famod commented Sep 7, 2021

Describe the bug

maven-compiler-plugin issues a warning when your app is using @ConfigProperty and compiler warnings are enabled:

[INFO] Compiling 1 source file to /home/famod/proj/quarkus-quickstarts/config-quickstart/target/classes
[WARNING] unknown enum constant org.osgi.annotation.bundle.Requirement.Resolution.OPTIONAL
  reason: class file for org.osgi.annotation.bundle.Requirement$Resolution not found

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=true in quarkus-quickstarts.

Output of uname -a or ver

Linux 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 -version

OpenJDK 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 --version or gradlew --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.

@quarkus-bot
Copy link

quarkus-bot bot commented Sep 7, 2021

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip.

This message is automatically generated by a bot.

@famod
Copy link
Member Author

famod commented Sep 7, 2021

/cc @radcortez

@radcortez
Copy link
Member

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 radcortez self-assigned this Sep 17, 2021
@famod
Copy link
Member Author

famod commented Sep 17, 2021

Thanks for looking into it!
I expected this to be an upstream issue right from the start and not something that can be fixed in SR Config (or even Quarkus).
That's why I added the upstream label and so I'm now a little surprised that you removed it. 🤔
But anyway, a label is just a label. 😉

@radcortez
Copy link
Member

Sorry, I've removed it because I thought this is already "triaged" and that we now have a linked issue to the upstream dependency.

@famod
Copy link
Member Author

famod commented Sep 17, 2021

Ah ok. I thought we also use it to flag issues that are waiting for upstream changes. 🤷‍♂️

bjhargrave added a commit to bjhargrave/osgi that referenced this issue Feb 7, 2022
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 <[email protected]>
@bjhargrave
Copy link

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.

@gsmet
Copy link
Member

gsmet commented Feb 7, 2022

I confirm the upstream label is added to mark issues that are waiting for an upstream fix. Ultimately, I'd like to remove them from our stats as there's nothing we can do about them.

bjhargrave added a commit to bjhargrave/osgi that referenced this issue Feb 7, 2022
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 <[email protected]>
bjhargrave added a commit to bjhargrave/bnd that referenced this issue Feb 7, 2022
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 <[email protected]>
bjhargrave added a commit to bjhargrave/bnd that referenced this issue Feb 7, 2022
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 <[email protected]>
bjhargrave added a commit to bjhargrave/osgi that referenced this issue Feb 7, 2022
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 <[email protected]>
bjhargrave added a commit to bjhargrave/bnd that referenced this issue Feb 7, 2022
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 <[email protected]>
@bjhargrave
Copy link

FYI, eclipse/microprofile-config#732 has been filed to update MicroProfile Config API to avoid the compiler warning issue.

@MarcusBiel
Copy link

Have that too for quite a while now :(

@famod
Copy link
Member Author

famod commented Mar 3, 2022

@MarcusBiel 2.7.3 should have fixed this (I haven't checked yet).

@gastaldi
Copy link
Contributor

gastaldi commented Mar 3, 2022

I can confirm this is fixed in 2.7.3.Final

@MarcusBiel
Copy link

Can't confirm since 2.7.3 doesn't work for me:
Build failure: Build failed due to errors
[error]: Build step io.quarkiverse.logging.logback.deployment.LoggingLogbackProcessor#init threw an exception: java.lang.NoClassDefFoundError: io/quarkus/bootstrap/resolver/update/DefaultArtifactVersion
at io.quarkiverse.logging.logback.deployment.LoggingLogbackProcessor.doVersionCheck(LoggingLogbackProcessor.java:196)
at io.quarkiverse.logging.logback.deployment.LoggingLogbackProcessor.init(LoggingLogbackProcessor.java:92)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

--
Probably a regression with https://quarkiverse.github.io/quarkiverse-docs/quarkus-logging-logback/dev/index.html
?

@gastaldi
Copy link
Contributor

gastaldi commented Mar 3, 2022

Better open an issue in the respective quarkiverse extension with a small reproducer

@famod
Copy link
Member Author

famod commented Mar 3, 2022

I can confirm this is fixed in 2.7.3.Final

Me too now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/config kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants