That’s specific to our build, Gary, in order to avoid running the processor on
modules that don’t need it. Typical users would probably only have a single
module with custom Log4j plugins.
> On Dec 4, 2024, at 09:19, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> I had to put some mysterious dot file in the root of my Maven module to get
> my plugin to work. The only way I found this is by comparison with another
> module but not all modules have this file.
>
> Gary
>
> On Wed, Dec 4, 2024, 8:16 AM Volkan Yazıcı <vol...@yazi.ci> wrote:
>
>> I agree with Pavel that users should only be required to
>>
>> 1. Provide the interface implementation
>> 2. Create the associated `META-INF/services` file entry
>> 3. [For Java 9 and above] Update their `module-info.java` accordingly
>>
>> Anything more than this is non-idiomatic. Telling users "but processors are
>> helpful", "you can manually create the Java file registering your plugin",
>> etc. is beating around the bush.
>>
>> On Fri, Nov 29, 2024 at 10:26 AM PavelTurk <pavelturk2...@gmail.com>
>> wrote:
>>
>>> Hi Piotr,
>>>
>>> On 11/29/24 10:07, Piotr P. Karwasz wrote:
>>>> Hi Pavel,
>>>>
>>>> On 28.11.2024 19:26, PavelTurk wrote:
>>>>> Thank you very much for your detailed and quick help.
>>>>>
>>>>> However, to tell the truth, I’m a bit confused. I’ve been waiting for
>> a
>>> long time for Log4j to finally work according to the JPMS rules. But in
>>> your message, you talk about compile-time and, as I understood, the use
>> of
>>> some plugin-processor (from your project pom):
>>>>>
>>>>> <annotationProcessorPaths>
>>>>> <path>
>>>>> <groupId>org.apache.logging.log4j</groupId>
>>>>> <artifactId>log4j-plugin-processor</artifactId>
>>>>> <version>3.0.0-beta3</version>
>>>>> </path>
>>>>> </annotationProcessorPaths>
>>>>>
>>>>> Doesn’t all this completely contradict JPMS?
>>>>> (...)
>>>>> By the way, I noticed something seemed off when I saw code duplication
>>> in your project:
>>>>>
>>>>> @Configurable(elementType = Appender.ELEMENT_TYPE, printObject = true)
>>>>> @Plugin(ConsoleAppender.PLUGIN_NAME)
>>>>> public final class ConsoleAppender...
>>>>>
>>>>> and
>>>>>
>>>>> PluginEntry.builder()
>>>>> .setKey("console")
>>>>>
>> .setClassName("org.apache.logging.log4j.core.appender.ConsoleAppender")
>>>>> .setName("Console")
>>>>> .setNamespace("Core")
>>>>> .setElementType("appender")
>>>>> .setPrintable(true)
>>>>> .get(),
>>>>>
>>>>> Or am I mistaken (which is always possible) and misunderstood
>>> everything?
>>>>
>>>> We have an annotation processor that automatically generates the
>>> required `PluginService` implementation, I don't see how that contradicts
>>> the principles behind JPMS.
>>> ...
>>>
>>> Let me explain my point of view. But first of all, I want to emphasize
>>> that I’m not claiming to be right—I could very well be wrong. I’m simply
>>> saying that using a processor seems incorrect to me.
>>>
>>> In the world of JPMS, there’s a service, we implement it, and we add it.
>> I
>>> haven’t heard of a service + PROCESSOR that needs to be used. Can you
>> point
>>> out any other projects that involve a service + processor? The reasoning
>> is
>>> that we should only need to know the INTERFACE, and we’ll handle the
>>> IMPLEMENTATION ourselves. After all, it’s possible to do without it—for
>>> example, by writing a PluginService manually, which would scan the module
>>> itself and return the necessary classes or just data(entries) about them.
>>> That’s why I said that using a processor here seems odd to me. In
>> general,
>>> I think code generation should only be used as a last resort—for example,
>>> for JPA metamodels—but that’s just my opinion.
>>>
>>> I assume module-info was also generated automatically. The problem is
>> that
>>> it’s not present in log4j-core-3.0.0-beta3-sources.jar see [1], but it
>> does
>>> exist in log4j-core-3.0.0-beta3.jar see [2]. Additionally, it’s not in
>> the
>>> repository see [3]. So, it is not possible to see what is in this file.
>> Or
>>> was I looking in the wrong place?
>>>
>>> [1]
>>>
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3-sources.jar
>>> [2]
>>>
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3.jar
>>> [3]
>>>
>> https://github.com/apache/logging-log4j2/tree/rel/3.0.0-beta3/log4j-core/src/main/java
>>>
>>> Best regards, Pavel
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>
>>>
>>
