I believe I have asked for a log4j-its module for a while now since that is the
only way you can validate modules actually work together. I am fine with it
being in a separate repo.
Ralph
> On Aug 8, 2024, at 11:35 PM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Unless I am mistaken, adding test
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
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
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
dependency between the module from `log4j-api` and the
> module of the test fixtures `log4j-api-test`.
> * only simple integration tests should go to a separate repo. These
> tests will verify, e.g., that we can run `log4j-core` without any of
> its optional dependencies.
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/issues/2814
>
odule of the test fixtures `log4j-api-test`.
* only simple integration tests should go to a separate repo. These
tests will verify, e.g., that we can run `log4j-core` without any of
its optional dependencies.
Piotr
[1] https://github.com/apache/logging-log4j2/issues/2814
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
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,
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 these tests:
* IntelliJ IDEA still complains that it doesn't know a
`org.apache.logging.log4j.core` module.
* These tests might be flaky
No, some internal thing.
> On Sep 14, 2023, at 3:50 PM, Gary Gregory wrote:
>
> Podman?
>
> On Thu, Sep 14, 2023, 4:42 PM Matt Sicker wrote:
>
>> I’ve switched from Docker and Docker Desktop to something new (not
>> Rancher), but it does expose Docker compatibility APIs, so not a problem
>> h
Podman?
On Thu, Sep 14, 2023, 4:42 PM Matt Sicker wrote:
> I’ve switched from Docker and Docker Desktop to something new (not
> Rancher), but it does expose Docker compatibility APIs, so not a problem
> here.
>
> > On Sep 13, 2023, at 4:40 PM, Ralph Goers
> wrote:
> >
> > Are you really switchi
I’ve switched from Docker and Docker Desktop to something new (not Rancher),
but it does expose Docker compatibility APIs, so not a problem here.
> On Sep 13, 2023, at 4:40 PM, Ralph Goers wrote:
>
> Are you really switching from Docker or just Docker Desktop? We moved to use
> Rancher due to
Check, TY!
On Wed, Sep 13, 2023 at 6:06 PM Ralph Goers wrote:
>
> As I said, we are using Rancher. It has worked pretty well so far.
>
> Ralph
>
> > On Sep 13, 2023, at 3:00 PM, Gary Gregory wrote:
> >
> > We are switch away from Docker Desktop, the replacement has not been
> > decided yet, any
As I said, we are using Rancher. It has worked pretty well so far.
Ralph
> On Sep 13, 2023, at 3:00 PM, Gary Gregory wrote:
>
> We are switch away from Docker Desktop, the replacement has not been
> decided yet, any advice?
>
> Gary
>
> On Wed, Sep 13, 2023 at 5:40 PM Ralph Goers
> wrote:
>
We are switch away from Docker Desktop, the replacement has not been
decided yet, any advice?
Gary
On Wed, Sep 13, 2023 at 5:40 PM Ralph Goers wrote:
>
> Are you really switching from Docker or just Docker Desktop? We moved to use
> Rancher due to the licensing problems with Docker Desktop. Bu
I am assuming the CI builds would still run natively as they do now. CI
workflows for integration tests should be free to use whatever tooling they may
need.
Ralph
> On Sep 12, 2023, at 11:33 PM, Piotr P. Karwasz
> wrote:
>
> Hi Volkan,
>
> On Wed, 13 Sept 2023 at 08
Are you really switching from Docker or just Docker Desktop? We moved to use
Rancher due to the licensing problems with Docker Desktop. But that still uses
K8S and Docker.
Ralph
> On Sep 13, 2023, at 6:13 AM, Gary Gregory wrote:
>
> FWIW, on my main (work) laptop, I am about to switch away
FWIW, on my main (work) laptop, I am about to switch away from Docker
on the desktop to another container solution (not sure which one yet).
Gary
On Wed, Sep 13, 2023 at 2:33 AM Piotr P. Karwasz
wrote:
>
> Hi Volkan,
>
> On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı wrote:
> > Though note that t
Those who are concerned can get themselves heard in this thread. In
the worst case, they can toggle the profile to suit their needs. You
are adding a crucial verification which wasn't there before and 2
other PMC members (Matt and I) agree with the implementation approach.
I don't see a blocker her
Hi Volkan,
On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı wrote:
> Though note that this will introduce a new requirement on the build
> hosts: Docker Engine accessibility. Hence, it is better to put these
> behind a Maven profile (`container`?) that one can opt out of.
This is my main concern, do
] that would allow us
> to test components against Docker images.
>
> AFAIK, the first three create an appropriate deployable artifact (OSGI
> bundle, WAR file) from our test class and deploy it to a container. I
> am not sure how Testcontainers work.
>
> Do you have any experien
the discussion about splitting the main repo Ralph raised the
> problem that we don't have reliable integration tests.
>
> Sure, most of our unit tests actually check the entire lifecycle of a
> logger context (which I think is a waste of testing time by the way),
> but t
Hi all,
During the discussion about splitting the main repo Ralph raised the
problem that we don't have reliable integration tests.
Sure, most of our unit tests actually check the entire lifecycle of a
logger context (which I think is a waste of testing time by the way),
but these are s
25 matches
Mail list logo
