Greetings!
The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase
One’ set for June 9th and ‘General Availability’ set for September 20th.
The next several weeks will be interesting to watch as the scope of JDK
19 is revealed.
You also play an important roll during these phas
Good point. Thank you, Matt.
On Tue, Apr 19, 2022 at 10:49 PM Matt Sicker wrote:
> If they cause an issue, it's trivial to exclude those dependencies in
> Maven, Gradle, or really any other build system. I suppose we can find
> out from users. :)
>
> On Tue, Apr 19, 2022 at 12:32 PM Tim Perry w
If they cause an issue, it's trivial to exclude those dependencies in
Maven, Gradle, or really any other build system. I suppose we can find
out from users. :)
On Tue, Apr 19, 2022 at 12:32 PM Tim Perry wrote:
>
> Will including `com.sun.activation:jakarta.activation` and
> `com.sun.mail:smtp` be
I am onboard with your thoughts Ralph; replacing 2.x JARs with 3.x rather
than keeping both, sticking to `log4j2.xml`, keeping API compatible with
2.x, etc. Though I also think 3.x constitutes a good opportunity to lose
some extra weight: deprecated or superseded Maven modules. (I know you are
addr
I propose we continue this discussion in the upcoming video call. It is
scheduled for the 1st of May. I have added this subject to the meeting
notes as a to-be-discussed.
On Mon, Apr 18, 2022 at 10:15 PM Ralph Goers
wrote:
>
>
> > On Apr 18, 2022, at 9:21 PM, Volkan Yazıcı wrote:
> >
> > Thanks
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 Sic
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
Gary has suggested that Log4j 3.x should be able to break binary compatibility
since it is a new major version and somehow should be able to coexist side by
side with Log4j 2. I am not really sure where he got that idea but I am going
to try to explain why that is not workable.
First, to have b
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.activati
