What, if any, Jakarta EE specifications must Config depend on?

[ljnelson]

Per our meeting last week, we identified three options:

1. None.
2. Jakarta Dependency Injection only.
3. Jakarta Contexts and Dependency Injection (CDI) (and therefore also Jakarta Dependency Injection).

Note that option 3 will introduce transitive dependencies on a subset of the following:

• Jakarta Annotations
• Jakarta Interceptors
• Jakarta Expression Language

[ljnelson]

I like option 1.

[ljnelson]

Note that choosing option 1, as I have, means that the Jakarta Config specification cannot define any qualifier annotations, since qualifiers belong to Jakarta Dependency Injection.

[radcortez]

Option 1.

[m0mus]

Option 1

[Emily-Jiang]

Option 1 for core
Option 2 for the injection support - in a separate jar

[hantsy]

I hope it is for core, but make CDI dependency optional(like the optional in maven dependency), if there is a CDI env, through CDI Extension to get support.

[dmlloyd]

Option 1. As I've stated separately however, the specification should define that dependency injection users should be able to inject configurations. We also should define general rules about how other specifications should consume this one.

If CDI itself consumes this specification, then the specific nature of this should be defined in the CDI spec, not here.

[dblevins]

Hey All, Not able to attend calls, so just looking for some insight. I know at least early MP Config work was kind of informally split into two APIs. One that was Java SE focused and deliberately had no dependency to other specs. I recall it was largely the Config instance and config sources. As it was plain Java SE it could be used in a server before any other components were started, like CDI, and could potentially be used to help build the server itself if impls wanted to take that route. The @ConfigProperty stuff was all obviously CDI-specific syntactic sugar and really a layer on top of the Java SE flavor of Config. Do any of the options presented materially change this and if so how?

…

-David

On Sep 19, 2022, at 1:05 PM, Laird Nelson ***@***.***> wrote: Per our meeting last week, we identified three options: None. Jakarta Dependency Injection <https://jakarta.ee/specifications/dependency-injection/> only. Jakarta Contexts and Dependency Injection (CDI) <https://jakarta.ee/specifications/cdi/> (and therefore also Jakarta Dependency Injection <https://jakarta.ee/specifications/dependency-injection/>). Note that option 3 will introduce transitive dependencies on a subset of the following: Jakarta Annotations <https://jakarta.ee/specifications/annotations/> Jakarta Interceptors <https://jakarta.ee/specifications/interceptors/> Jakarta Expression Language <https://jakarta.ee/specifications/expression-language/> — Reply to this email directly, view it on GitHub <#116>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXFTUE6PSWVHVNAB4K2LTV7DBPXANCNFSM6AAAAAAQQNQF54>. You are receiving this because you are subscribed to this thread.

[radcortez]

One of the issues with MP Config is that both APIs are shipped in the same JAR, and the TCK is mostly CDI-centric.

Yes, it is possible to use the current MP Config API in a SE only environment, but I think it confuses the user by including @ConfigProperty and @ConfigProperties which require a CDI container (even if they are not used). I believe this creates a wrong impression that CDI is needed and pushes candidate implementors outside the Jakarta / MP area to use the spec.

One of the proposals is to split the APIs and the spec. This would allow us to provide only what is required for Java SE and provide a TCK that does not rely on CDI.

[otaviojava]

Option 1