But why would we do this? What advantage does it have over just including the bom pom.xml in the main project? Surely we will have many more releases of that than any of the sub-projects? If each release has an up-to-date bom pom.xml then it is actually fulfilling its purpose.
Ralph > On Jun 11, 2021, at 8:47 AM, Matt Sicker <boa...@gmail.com> wrote: > > Right, a release train BOM would be its own repo basically for making > periodic dependency update releases (typically can be done around the > same time as the referenced components being released). Release trains > could either be a single log4j train or multiple trains like how > Spring has multiple projects (probably too much overhead for us?). > > On Fri, 11 Jun 2021 at 10:44, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I agree with you there. Gary is correct that it would be difficult for users >> to >> keep track of all of this without such a mechanism. The fact is though that >> we already have it. The log4j-bom pom.xml is already included in every >> log4j release. We simply have to ensure that it always contains the correct >> versions of the artifacts. >> >> If we did this though, it might make more sense for every project to have >> its own bill of materials pom.xml and for the main log4j bom to import all of >> those instead of naming every individual artifact. >> >> If we do this I would suggest that we also consider the impact to the web >> site. I would not want to see all of these have their own web sites but >> continue to be integrated into the main web site. At the same time though, >> we would need to make it easy for users to locate the git repos for the >> components they are looking for. GitHub’s search mechanism doesn’t make >> it easy to find only the Apache logging projects, let alone just those >> related >> to log4j. >> >> I would also suggest that no matter what we do we will have to consider the >> impact to the web site if both release-2.x and master are being supported. >> We could imitate Tomcat and have a main web site that links to prior >> versions or we could try to modify the 3.0 web site to document what is new >> and different while keeping the doc for 2.x. >> >> I will admit though, that although Spring does this fairly successfully their >> process is a bit different than what I am imagining here. Every Spring >> component >> releases on its own schedule. Periodically Spring Boot and Sprint Cloud each >> have their own releases of all the components packaged together. In Log4j >> terms that would essentially mean that the log4j-bom project would be >> extracted >> from the main project and periodically it would be released all by itself. >> >> Ralph >> >>> On Jun 11, 2021, at 7:43 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: >>> >>> I definitely agree with this. This is such a convenience while using Spring. >>> >>> On Fri, Jun 11, 2021 at 4:07 PM Matt Sicker <boa...@gmail.com> wrote: >>> >>>> If we end up breaking up the modules and releasing them independently, I >>>> suggest we also adopt a release train mechanism to collect them together >>>> into single version BOM-style POM files. Also, if independent releases are >>>> faster to make and faster to verify, then we can make them more often. >>>> >>>> On Fri, Jun 11, 2021 at 05:22 Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>>> From my POV, this will create an incomprehensible mess of versions for >>>>> users. Big bummer. >>>>> >>>>> Gary >>>>> >>>>> On Fri, Jun 11, 2021, 04:29 Volkan Yazıcı <volkan.yaz...@gmail.com> >>>> wrote: >>>>> >>>>>> To start the discussion for breaking up the modules into separate >>>>> projects, >>>>>> I propose the following structure: >>>>>> >>>>>> *logging-log4j* >>>>>> log4j-1.2-api >>>>>> log4j-api >>>>>> log4j-bom >>>>>> log4j-core >>>>>> log4j-core-its >>>>>> log4j-gctests >>>>>> log4j-iostreams >>>>>> log4j-layout-template-json >>>>>> log4j-perf >>>>>> log4j-plugins >>>>>> >>>>>> *logging-log4j-appender* >>>>>> log4j-cassandra >>>>>> log4j-couchdb >>>>>> log4j-csv >>>>>> log4j-flume-ng >>>>>> log4j-mongodb3 >>>>>> log4j-mongodb4 >>>>>> log4j-smtp >>>>>> >>>>>> *logging-log4j-appender-jdbc* >>>>>> log4j-jdbc (?) >>>>>> log4j-jdbc-dbcp2 (?) >>>>>> log4j-jpa >>>>>> >>>>>> *logging-log4j-appender-queue* >>>>>> log4j-jeromq >>>>>> log4j-jms >>>>>> log4j-kafka >>>>>> log4j-redis >>>>>> >>>>>> *logging-log4j-binding* >>>>>> log4j-jcl >>>>>> log4j-jpl >>>>>> log4j-jul >>>>>> log4j-liquibase >>>>>> log4j-slf4j18-impl >>>>>> log4j-slf4j-impl >>>>>> log4j-to-slf4j >>>>>> >>>>>> *logging-log4j-container* >>>>>> log4j-docker >>>>>> log4j-kubernetes >>>>>> >>>>>> *logging-log4j-gui* >>>>>> log4j-jmx-gui >>>>>> >>>>>> *logging-log4j-jee* >>>>>> log4j-appserver >>>>>> log4j-taglib >>>>>> log4j-web >>>>>> >>>>>> *logging-log4j-layout-jackson* >>>>>> log4j-layout-jackson >>>>>> log4j-layout-jackson-json >>>>>> log4j-layout-jackson-xml >>>>>> log4j-layout-jackson-yaml >>>>>> >>>>>> *logging-log4j-osgi* >>>>>> log4j-osgi >>>>>> >>>>>> *logging-log4j-spring* >>>>>> log4j-spring-boot >>>>>> log4j-spring-cloud-config >>>>>> >>>>>> Note that above breakdown contains every available module in master, >>>>> except >>>>>> log4j-samples, which has the following sub-modules: >>>>>> >>>>>> log4j-samples-loggerProperties (contains 2 very trivial example >>>> classes, >>>>>> log4j-core [tests] contains more comprehensive alternatives) >>>>>> log4j-samples-flume-remote (flume-specific) >>>>>> log4j-samples-flume-embedded (flume-specific) >>>>>> log4j-samples-flume-common (flume-specific) >>>>>> log4j-samples-configuration (contains 3 very trivial example classes, >>>>>> log4j-core [tests] contains more comprehensive alternatives) >>>>>> >>>>>> I propose removing log4j-samples module and, if necessary, moving >>>>>> Flume-related parts to the log4j-flume-ng. >>>>>> >>>>>> I have kept log4j-layout-template-json in the logging-log4j project, >>>>> since >>>>>> it has no external dependencies. This said, I am okay with moving it >>>> to a >>>>>> separate logging-log4j-layout project. >>>>>> >>>>>> Please share your remarks. Eventually, I want to translate this into a >>>>> JIRA >>>>>> ticket. >>>>>> >>>>>> Kind regards. >>>>>> >>>>>> On Thu, Jun 10, 2021 at 5:43 PM Ralph Goers < >>>> ralph.go...@dslextreme.com> >>>>>> wrote: >>>>>> >>>>>>> Gary, >>>>>>> >>>>>>> I am -1 to almost every item on your list. >>>>>>> >>>>>>> When I said break up I meant mostly moving most everything outside of >>>>>>> log4j-core, >>>>>>> log4j-api, and log4j-plugins into separate repos such as >>>>>>> logging-log4j-nosql, >>>>>>> logging-log4j-pubsub, etc. These would not require groupId or >>>>> artifactId >>>>>>> changes >>>>>>> although the versioning would potentially be out of synch with the >>>> main >>>>>>> releases >>>>>>> as each would be on its own release cycle. This would greatly >>>> simplify >>>>>>> releasing >>>>>>> core but it would require careful though on what the versions would >>>> be >>>>>> for >>>>>>> the >>>>>>> “extra” projects. >>>>>>> >>>>>>> As for further breaking up core, that should revolve primarily around >>>>>>> reducing the >>>>>>> dependencies listed in module-info.java to the bare minimum. >>>>>>> >>>>>>> There will be no log4j3. We cannot change groupIds, artifactIds, or >>>>>>> package names, >>>>>>> other than what has been done to support JPMS. A world in which a >>>>> log4j2 >>>>>>> and >>>>>>> log4j3 try to co-exist would be an unmitigated disaster. Commons can >>>>>>> happily get >>>>>>> away with that. Log4j cannot. >>>>>>> >>>>>>> If an application had both log4j2 and log4j3 jars present they would >>>>> end >>>>>>> up with >>>>>>> multiple LoggerContexts, multiple Configurations, and multiple >>>> Appender >>>>>>> Managers >>>>>>> where today there is only a single one. That would mean two instances >>>>> of >>>>>>> the same >>>>>>> configuration file would be active at once. So when it is time to >>>>>> rollover >>>>>>> it would >>>>>>> be performed twice instead of once as a simple example. For this >>>> reason >>>>>> we >>>>>>> CANNOT break backward compatibility. >>>>>>> >>>>>>> However, we are talking about runtime backward compatibility. The >>>>> Plugin >>>>>>> system >>>>>>> was changed internally in 3.0 so that plugins compiled with 3.0 use >>>>>>> ServiceLoader >>>>>>> instead of the data file. However, it will still find and use 2.x >>>>> plugins >>>>>>> when they are >>>>>>> present and can be located. >>>>>>> >>>>>>> The meaning of this should be clear. It is 3.0 because to take >>>>> advantage >>>>>>> of its >>>>>>> features you may have to make code changes. But it will tolerate code >>>>>> that >>>>>>> was >>>>>>> compiled for 2.x. >>>>>>> >>>>>>> The reasons why it is 3.0 and not a simple upgrade to 2.x are: >>>>>>> 1. Plugins must be compiled with 3.0 to use the ServiceLoader >>>>> packaging. >>>>>>> 2. It requires Java 11. We still need to support Java 8. >>>>>>> 3. It fully supports JPMS. Release 2.x does not. It is likely that >>>>>>> applications with >>>>>>> multiple Module Layers might not be able to find all the plugins. >>>>> Adding >>>>>>> full JPMS >>>>>>> support to 2.x simply isn’t possible. >>>>>>> 4. It will be introducing new DI injection features not present in >>>> 2.x. >>>>>>> >>>>>>> Major releases do not imply that you are completely breaking backward >>>>>>> compatibility. >>>>>>> They imply that some kind of compatibility is broken, which we are >>>>> doing >>>>>>> by >>>>>>> requiring coding changes to Plugins to compile with 3.0. This means >>>> we >>>>>>> need to >>>>>>> leave in any classes or methods that existing plugins might have >>>> used. >>>>> It >>>>>>> means >>>>>>> we have to continue using our own Supplier unless it can be verified >>>>> that >>>>>>> an >>>>>>> application using the Supplier in 2.x can run with 3.0 even if it is >>>>>>> converted to >>>>>>> java.util.function.Supplier. I have no idea if the code the compiler >>>>>>> generates >>>>>>> for lambdas actually implements the declared interface or not. >>>>>>> >>>>>>> Log4j 3.0 is a major change. But that doesn’t mean we can screw our >>>>> users >>>>>>> by >>>>>>> breaking everything. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 10, 2021, at 6:32 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> These are all IMOs of course, YMMV: >>>>>>>> - What's the rush to 3.0? >>>>>>>> >>>>>>>> - I'm all for breaking up the core and other artifacts into more >>>>>>>> artifacts based on their dependencies requirement such that >>>> depending >>>>>>>> on Log4j 3 does not "suck in the world", for example, I should be >>>>> able >>>>>>>> to depend on a currently non-existent "log4j3-console" and only >>>> bring >>>>>>>> in a tiny bit of code (API, a tiny core, and no plugin system). I >>>> did >>>>>>>> a fair amount of breaking up of various artifacts a while back. >>>>>>>> >>>>>>>> - 3.0 is a MAJOR release that gives us the opportunity to drop >>>>>>>> deprecated APIs and code like our custom functional interfaces: >>>>>>>> Supplier and so on. If we do not clean up, then there is no point >>>> in >>>>> a >>>>>>>> major release. Basically, I expect to break binary and source >>>>>>>> compatibility. >>>>>>>> >>>>>>>> - 3.0 must be in a new package namespace and new Maven >>>> coordinates. I >>>>>>>> MUST be able to run Log4j 1, 2, and 3 in the same class loader. I >>>> can >>>>>>>> already run Log4j 1 and 2 side by side which is good. >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> On Thu, Jun 10, 2021 at 8:47 AM Volkan Yazıcı < >>>>> volkan.yaz...@gmail.com >>>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>> Ralph, count me in for such a change. I really want to have >>>> separate >>>>>>>>> sub-projects for such modules. This will extremely speed up >>>>>>> build/release >>>>>>>>> times too, which is nowadays of uttermost importance to my peace >>>> of >>>>>> mind >>>>>>>>> while developing. >>>>>>>>> >>>>>>>>> This said, I am reluctant about such a major change when we are >>>> this >>>>>>> close >>>>>>>>> to the 3.0.0 release. I guess this would definitely postpone the >>>>> 3.0.0 >>>>>>>>> release to 2022. This will probably break the backward >>>> compatibility >>>>>> at >>>>>>>>> least for the artifact groupId, am I wrong? Not to mention that >>>> the >>>>>>> entire >>>>>>>>> website needs to be adapted to this multi-project setup too. Is >>>>> there >>>>>>>>> anything else? >>>>>>>>> >>>>>>>>> On Thu, Jun 3, 2021 at 5:31 PM Ralph Goers < >>>>>> ralph.go...@dslextreme.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Yeah - I have proposed moving all these extra integrations to a >>>>>>> separate >>>>>>>>>> repo but >>>>>>>>>> I’ve never gotten consensus. I’d prefer to have a project like >>>>>>>>>> log4j-pubsub where >>>>>>>>>> things like JMS, JeroMQ, etc can go live, log4j-nosql for all the >>>>>> nosql >>>>>>>>>> modules, etc. >>>>>>>>>> The problem seems to be that some people believe that we would >>>> have >>>>>> to >>>>>>> cut >>>>>>>>>> a >>>>>>>>>> release of those every time we do a log4j release. >>>>>>>>>> >>>>>>>>>> If we were to do that 3.0 would be the right time. >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >
