Hi Matt,
On Fri, 9 Aug 2024 at 22:54, Matt Sicker wrote:
>
> A 3.x version of `log4j-jul` isn’t strictly necessary as long as we have a
> META-INF/versions/9/module-info.class file in the jar.
Sure, but `log4j-jul` has some classes that use Log4j Core (to modify
the configuration using JUL). Si
A 3.x version of `log4j-jul` isn’t strictly necessary as long as we have a
META-INF/versions/9/module-info.class file in the jar.
> On Aug 9, 2024, at 15:35, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On Fri, 9 Aug 2024 at 20:29, Matt Sicker wrote:
>>
>> Well, one thing that changed in JUL is
Hi Matt,
On Fri, 9 Aug 2024 at 20:29, Matt Sicker wrote:
>
> Well, one thing that changed in JUL is that it requires the java.logging
> module. Otherwise, the Java 8+ stuff is for the System.Logger API.
Right, maybe a 3.x version of `log4j-jul` would be useful. Besides the
artifact has an optio
Hi Matt,
On Fri, 9 Aug 2024 at 20:28, Matt Sicker wrote:
>
> Commons libraries are generally self-contained to the point where modularity
> isn’t a problem. Things get complicated once you start involving split up
> modules like APIs, SPIs, alternate implementations, and reflection-heavy
> des
This looks amazing! Thanks for all the work, everyone!
> On Aug 9, 2024, at 02:01, Piotr P. Karwasz wrote:
>
> Hi all,
>
> We finished revamping the documentation of Log4j 2. The result is
> available on the staging site:
>
> https://logging.staged.apache.org/log4j/2.x/
>
> The new version sh
Commons libraries are generally self-contained to the point where modularity
isn’t a problem. Things get complicated once you start involving split up
modules like APIs, SPIs, alternate implementations, and reflection-heavy design
patterns that otherwise bypass language rules around member acces
Well, one thing that changed in JUL is that it requires the java.logging
module. Otherwise, the Java 8+ stuff is for the System.Logger API.
> On Aug 9, 2024, at 07:20, Piotr Karwasz wrote:
>
> Hi Ralph,
>
> On 2024/04/09 21:46:28 Ralph Goers wrote:
>>> On Apr 9, 2024, at 12:34 PM, Piotr P. Kar
We do not test the module path.
"Among the problems that tools like BND or Moditect might"
So? Then we or others report and fix those tools. If moditect does not work
100% it's no reason to do all this JPMS junk manually. These are all open
source tools, so we can all play nicely together and rep
Hi Gary,
On Fri, 9 Aug 2024 at 15:24, Gary Gregory wrote:
> I've had many requests to support JPMS in Commons and none that I recall
> since I've been releasing jars using Moditect, so I can only assume it
> works well enough. My impression is that people only care to get rid of
> warnings or err
I know enough of the Eclipse setup to say that it works and that's it.
I've had many requests to support JPMS in Commons and none that I recall
since I've been releasing jars using Moditect, so I can only assume it
works well enough. My impression is that people only care to get rid of
warnings or
Hi Gary,
On Fri, 9 Aug 2024 at 13:18, Gary Gregory wrote:
> I use Eclipse to create PRs for projects like Jetty 12 which has 200+ Maven
> modules. How is this not a problem there?
I don't see any `module-info.java` file in Jetty tests. Are they even
running tests on the module path?
> In Common
Hi Ralph,
On 2024/04/09 21:46:28 Ralph Goers wrote:
> > On Apr 9, 2024, at 12:34 PM, Piotr P. Karwasz
> > wrote:
> > Since Log4j Core 3.x moved to `log4j-api` 2.24.0, many artifacts that
> > only depend on `log4j-api` became redundant in the 3.x branch:
> >
> > * `log4j-iostreams`,
> > * `log4j
I use Eclipse to create PRs for projects like Jetty 12 which has 200+ Maven
modules. How is this not a problem there?
In Commons, we use the Moditect plugin to generate the JPMS junk, no
problems. No need for the insanity of special test projects.
It feels like we are doing something wrong here..
Hi Gary,
On Fri, 9 Aug 2024 at 12:00, Gary Gregory wrote:
>
> I hope you mean a new maven module and not a whole new git repo...
Unfortunately I mean repo. The problem is that IDEs (even commercial
ones like IntelliJ IDEA) barely handle JPMS and have big problems with
the way we generate JPMS mo
FYI
While it is a different community, I have received negative feedback in
Commons against the trend to spread information all over the place, and we
don't use GitHub.
The TLDR is that in the past it was easier to find information because you
only had the mailing list and later Jira. Now you hav
I hope you mean a new maven module and not a whole new git repo...
Gary
On Fri, Aug 9, 2024, 2:35 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> Unless I am mistaken, adding tests that run under JPMS is problematic
> in the `apache/logging-log4j2` repository. Even if I create a new
> Maven module for
Hi all,
As specified in the `.asf.yaml` documentation, I am opening this
thread to test the consensus on enabling Github discussions for
`logging-log4j-kotlin` and `logging-log4j-scala`.
Do you have anything against enabling this feature?
Piotr
BTW: an INFRA ticket is already open[2].
[1]
htt
Hi all,
We finished revamping the documentation of Log4j 2. The result is
available on the staging site:
https://logging.staged.apache.org/log4j/2.x/
The new version should be:
* visually more appealing.
* takes advantage of AsciiDoc admonition blocks and tabbed code blocks
to help users find i
18 matches
Mail list logo
