> On Jun 19, 2021, at 11:42 AM, Volkan Yazıcı wrote:
>
> Why do we need both a -test and -unittest modules? Can't we configure
> surefire and failsafe to simply run the tests in the "main" of -test module?
a) The way Maven currently supports JPMS unit testing I can’t be sure that
placing the
Why do we need both a -test and -unittest modules? Can't we configure
surefire and failsafe to simply run the tests in the "main" of -test module?
A back of the envelope calculate yields the following:
$ grep 'test-jar' -RHn . -C 3 | grep 'log4j' | sed
-r 's/.*(.*)<\/artifactId>/\1/g' | sort | un
If you did that then it would require that instead of the Log4j-api module
producing the log4j-api jar and log4j-api test jar you would end up with
* log4j-api - with no tests.
* log4j-api-test - creates the test jar.
* log4j-api-unittest - contains and runs the unit tests.
I’d rather live with
I think the idea would be to separate the reusable test code into their own
main modules which depend on JUnit and such which are only consumed by test
modules. I think this approach could potentially work, but we’d end up with
a few more published jars.
On Sat, Jun 19, 2021 at 11:28 Ralph Goers
> On Jun 19, 2021, at 3:45 AM, Volkan Yazıcı wrote:
>
> That README is such a gem Ralph! Thanks for documenting all that suffering.
> (README says Log4j 2 supports JPMS, shouldn't it rather be Log4j 3?)
No, I consider it Log4j 2 version 3.0. IOW, the 2 is just part of the name. I
can see
wh
That README is such a gem Ralph! Thanks for documenting all that suffering.
(README says Log4j 2 supports JPMS, shouldn't it rather be Log4j 3?)
There are actually pretty few modules whose test JARs are used by the
downstream, mostly by log4j-perf. Could it be a viable option to move the
benchmark
> On Jun 18, 2021, at 2:19 PM, Jochen Wiedmann
> wrote:
>
> On Fri, Jun 18, 2021 at 6:20 PM Ralph Goers
> wrote:
>
>> 2. The configuration does “strange things” because Maven doesn’t support
>> creating a
>> JPMS module, JPMS test module, and running unit tests in a single Maven
>> modul
On Fri, Jun 18, 2021 at 6:20 PM Ralph Goers wrote:
> 2. The configuration does “strange things” because Maven doesn’t support
> creating a
> JPMS module, JPMS test module, and running unit tests in a single Maven module
> out of the box while also avoiding
> https://bugs.java.com/bugdatabase/vi
> On Jun 18, 2021, at 8:05 AM, Jochen Wiedmann
> wrote:
>
> On Wed, Jun 16, 2021 at 1:31 PM Volkan Yazıcı wrote:
>
>> In essence, the build is taking more than it should. Maven "verify" is
>> taking more than half an hour and "site" is taking ages. This in addition
>> to impeding the develo
On Wed, Jun 16, 2021 at 1:31 PM Volkan Yazıcı wrote:
> In essence, the build is taking more than it should. Maven "verify" is
> taking more than half an hour and "site" is taking ages. This in addition
> to impeding the development cycle, cripples the release process too.
And why do you blame th
I know that Gradle supports Build cache locally and remotely (see [1]).
This can be useful to speed-up the process.
Gradle also provides parallel build (there are other features related to
performance here [2])
I'm unable to provide some concrete thoughts on how that may work for Log4J
because I'm
Regarding distributed compilation... We can get in touch with ASF to have
some VMs for a build farm. That is, we will still run the build locally,
though the compilation will be delegated to a cluster of nodes, which in
return will speed up the process notably. Back in my graduate days, I was a
big
> On Jun 16, 2021, at 8:29 AM, Matt Sicker wrote:
>
> I should note some possible benefits we could get from Bazel in theory:
>
> * Ability to offload builds/tests/etc. to remote build clusters. If
> you've ever used things like distcc for compiling things across
> multiple machines (handy fo
I should note some possible benefits we could get from Bazel in theory:
* Ability to offload builds/tests/etc. to remote build clusters. If
you've ever used things like distcc for compiling things across
multiple machines (handy for compiling C or C++ binaries for example),
it sounds similar.
* Ab
Actually, Maven has done a decent job of supporting modules for “standard”
projects.
Our issue is that we are creating a test jars in log4j-api, log4j-core, and
log4j-plugins.
These also need to comply with JPMS which means they can’t use the same package
space as the module they are part of.
I’ve noticed that attempting to support Java modules properly with Maven
requires a lot of non standard configuration. I don’t know if anything can
help there.
On Wed, Jun 16, 2021 at 07:11 Jeanderson wrote:
> Thanks for the input Volkan!
>
>
> > By switching to another build tool (Bazel or anyt
Thanks for the input Volkan!
> By switching to another build tool (Bazel or anything else), I expect to
> speed up these processes, maybe, by having more fine-grained control on the
> dependency graph and avoiding unnecessary steps.
>
I see quite often people switching from Maven to Gradle becau
In essence, the build is taking more than it should. Maven "verify" is
taking more than half an hour and "site" is taking ages. This in addition
to impeding the development cycle, cripples the release process too.
By switching to another build tool (Bazel or anything else), I expect to
speed up th
Hi all,
I'm not particularly involved with Log4J development but I've been
following this list for a few months now just because I'm curious about
Log4J development (and also because I'm also doing some R&D related to
logging). In fact, this is my first ever post here.
May I ask some clarifying q
*[First and foremost, this is my personal Tweet and there I explicitly
stated that "*I* can offer" the amount for such a work. After completing
such a project, we need to have a consensus within us to merge it. I want
to explicitly avoid any unintended misunderstandings.]*
Gary, it was you who sai
20 matches
Mail list logo
