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.

In addition, JPMS has impacts on the way the annotation process works. We 
always 
needed a separate compile step to first compile the annotation processor and 
then 
compile everything while using it. JPMS complicates this since a 
module-info.java 
cannot be present when compiling the annotation processor due to the compiler 
bug 
I encountered. Annotation processing is also complicated for other modules 
since it 
checks for a module-info.java even when proc=only is specified.

FWIW, the compiler bug I encountered has been fixed in Java 17. I don’t know if 
they will back port it to any earlier releases. I am quite certain I could 
simplify the 
build if we require the Java 17 compiler be used.

In short, Maven isn’t the cause of why log4j-api, log4j-core, and log4j-plugins 
are 
so complicated. It is almost entirely due to JPMS and our use of annotation 
processing.

Ralph

> On Jun 16, 2021, at 7:09 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> 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 <jeanderso...@gmail.com> wrote:
> 
>> 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 because Gradle
>> gives some flexibility on customizing the build cycle
>> and also because some people find it more convenient to use a scripting
>> language (rather than XML) to define the build process.
>> It seems to be a positive point in favor of Gradle when it comes to fine
>> tuning the build.
>> 
>> Still, I'm curious about the use of Gradle in a monorepo.
>> Is there some particular reason to think that Gradle is not a good fit for
>> Log4J?
>> 
>> About keeping Maven, wouldn't it be an alternative to use Build Profiles
>> [1] to skip unnecessary tasks?
>> 
>> If others want to share some thoughts on the topic, it would be good too.
>> Maybe, that's something that I can do some investigation and contribute to
>> the community.
>> 
>> [1]
>> https://maven.apache.org/guides/introduction/introduction-to-profiles.html
>> 
>> Best,
>> Jeanderson Candido
>> 


Reply via email to