Well my thing only worked after I added it. And people can only copy what
we do...
Gary
On Wed, Dec 4, 2024, 12:31 PM Matt Sicker <m...@musigma.org> wrote:
> 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
> >>>
> >>>
> >>
>
>
