It also feels to magical to me especially in large software stacks where asynchronous logging could be enabled just because some transitive dependency brings in a jar. Worse, that jar could be brought in even if declared optional. Some of this depending how a final application is delivered on disk or as a download. So in this case, it feels like enablement by presence only and not by declaration is too mysterious and surprising.
Gary On Mon, Jun 19, 2023, 16:25 Ralph Goers <ralph.go...@dslextreme.com> wrote: > If it were possible, I do wish the async logger stuff could be in a > separate maven module. In some ways it could be simpler by just having > everything be async by default if the module is present. However, I suspect > that being able to do this would require more time than any of us has. > > Ralph > > > On Jun 19, 2023, at 11:25 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi Gary, > > > > On Mon, 19 Jun 2023 at 15:01, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> > >> I like the idea of not having any optional dependencies by using Maven > >> modules. > > > > I would also like to remove optional dependencies entirely from the > > published POM, but I think it is impossible with the current Maven > > plugins. > > > > My proposal is less ambitious: we would still have > > `com.lmax:disruptor` as optional dependency of `log4j-core`, but we > > could also have a `log4j-starter-async` that depends (non-optionally) > > on `com.lmax:disruptor` and `log4j-core`. This way users don't have to > > manually manage the version of `com.lmax:disruptor`. > > > > Removing optional dependencies entirely is possible in Gradle: e.g. > > `spring-boot` has a lot of optional dependencies (cf. > > build.gradle[1]), but they don't appear in the published POM (cf. > > MvnRepository[2]). > > > > Piotr > > > > [1] > https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot/build.gradle > > [2] > https://mvnrepository.com/artifact/org.springframework.boot/spring-boot/3.1.0 > >