On Wed, Apr 14, 2021 at 12:43 AM Ralph Goers
wrote:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> since have fully modular
On Wed, Apr 14, 2021 at 1:41 AM Matt Sicker wrote:
> The picocli reference is likely for type conversion. Possibly removable.
>
Agreed, yes.
Actually, weren't picocli and all CLI tools moved to log4j-tools or
log4j-server or something?
> On Tue, 13 Apr 2021 at 11:34, Ralph Goers
> wrote:
> >
You did. But we still have stuff using the dependencies.
Ralph
> On Apr 13, 2021, at 12:05 PM, Gary Gregory wrote:
>
> I thought I already did a lot of that moving around of code to new modules
> in master a long time ago, I might be remembering wrong, AFK ATM.
>
> Gary
>
> On Tue, Apr 13, 20
I thought I already did a lot of that moving around of code to new modules
in master a long time ago, I might be remembering wrong, AFK ATM.
Gary
On Tue, Apr 13, 2021, 12:17 Matt Sicker wrote:
> The SQL code is all related to JDBC and related appenders which could go in
> their own module. The
That is what is concerning. A lot of those items have already been moved to
their own modules in master. Yet we still have these dependencies.
Ralph
> On Apr 13, 2021, at 10:53 AM, Jochen Wiedmann
> wrote:
>
> On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers
> wrote:
>
>> We also have dependenc
On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers wrote:
> We also have dependencies on things like java.rmi, java.naming, java.sql. I
> am also not clear on whether they are all really optional or not. Ideally,
> the only required dependency we should have is for java.base.
Most likely, those depen
The picocli reference is likely for type conversion. Possibly removable.
On Tue, 13 Apr 2021 at 11:34, Ralph Goers wrote:
>
> I just got an email reply to the issue I created for the Disruptor. They
> created a release this morning with the automatic module name so I should be
> able to pick th
I just got an email reply to the issue I created for the Disruptor. They
created a release this morning with the automatic module name so I should be
able to pick that up fairly soon.
/Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/c
The SQL code is all related to JDBC and related appenders which could go in
their own module. The naming is primarily used for EE stuff which could all
be split out (plus, I don’t think it’s in the default Android variant of
Java). The RMI thing can probably be replaced as you suggested.
JMX/manage
I started doing the work to modularize log4j-core last night. We have a blocker
in that the disruptor has not had a release in 3 years. They committed the
change to make it an automatic module over a year ago and since have fully
modularized it. They simply haven’t performed a release.
As I was
Hi Robert,
Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem
when including the log4cxx root directory from a higher level
CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the top-most
CMakeLists.txt file resides.
You are using ${CMAKE_SOURCE_DIR} in src/main
Guten Tag Robert Middleton,
am Dienstag, 13. April 2021 um 04:09 schrieben Sie:
> Before I go and do a release of log4cxx, are there any issues that may
> need to be taken care of before the next release?[...]
Including the latest PR makes sense, the more docs the better. :-)
https://github.com/
12 matches
Mail list logo