As with the old Java EE dependencies on the APIs, the same pattern still applies to Jakarta EE via the "provided" scope (or "compileOnly" configuration when using Gradle).
For the second point, I'd lean toward including the dependencies in those cases. You could make them "runtime" scope to avoid using any classes from it at compile time, though. On Tue, Apr 19, 2022 at 3:44 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hello, > > I just pushed the `log4j-jakarta-smtp` to `release-2.x`. Thanks to many > comments and suggestions in the PR it works as expected, but I have some > doubts on the Maven dependency pattern to apply to the artifact. > > In practice the artifact: > > 1. Directly references classes from > `jakarta.activation:jakarta.activation-api` and > `jakarta.mail:jakarta.mail-api`, but since all known implementations of > those APIs shade those artifacts instead of depending on them, I put those > dependencies as optional compile dependencies. Should they be 'provided' > dependencies? > 2. There is in practice a single implementation of the two APIs above, so > to help users of standalone and light servlet container applications I > added `com.sun.activation:jakarta.activation` and `com.sun.mail:smtp` (a > lighter version of `com.sun.mail:jakarta.mail` with just the SMTP provider) > as non-optional runtime dependencies. Should they be optional dependencies? > > Piotr
