Will including `com.sun.activation:jakarta.activation` and `com.sun.mail:smtp` be a problem on application servers that already include implementations of them? My knowledge of the J2EE application servers is incomplete for the modern (Java 11+) versions.
On Tue, Apr 19, 2022 at 5:05 PM Matt Sicker <boa...@gmail.com> wrote: > 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 >
