I must be missing something, I don't see the problem. Users wouldn't have both the combined jar and the single-module jars on the classpath together, so there should not be an issue...
For example, assume our current log4j-core jar is split up into * log4j-core-slim * log4j-core-appender-db * log4j-core-appender-mom * log4j-core-appender-net That is 4 jars where we used to have 1. Now, the combined jar ("log4j-core-all", for example) would have all classes of the above 4 jars. Users can then use log4j-core-all + log4j-api similar to how they currently do, no? Are you worried about users combining log4j-core-all with log4j-core-appender-db? Remko (Shameless plug) Every main() method deserves http://picocli.info > On Apr 25, 2017, at 2:55, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Guess what? If I am understanding Stephen correctly uber jars are not going > to work as you can’t have multiple modules that export the same package. > > Ralph > >> On Apr 24, 2017, at 10:43 AM, Remko Popma <remko.po...@gmail.com> wrote: >> >> How many new modules are we talking about, concretely? >> >> Matt mentioned the StackOverflow questions about transitive dependencies >> etc, but I imagine splitting log4j-core into 5 or more new modules will >> also cause confusion... It won't be trivial for users to figure out which >> of the many modules they do or don't need. The coarse granularity of the >> current modules is a good thing for users. >> >> What problem are we trying to solve? And how can we solve it with the least >> disruption to our users? >> >> Would it be an idea, for example, to provide separate jars for the separate >> modules, but in addition create a combined jar (log4j-core-all) that >> contains all the classes in log4j-core as well as the classes in the new >> modules we split out from core? >> >> >>> On Tue, Apr 25, 2017 at 2:00 AM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> I agree with Ralph here. I'm sure we'll figure out rather quickly which >>> modules are easy to put into rarely updated repositories. >>> >>>> On 24 April 2017 at 11:39, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>>> >>>> I would prefer a hybrid approach. First things should be moved to >>>> separate modules. Then, if they don’t seem to be modified frequently they >>>> can be moved to a separate repo. For example, I think it would be OK for >>>> the Flume Appender to be in a separate repo. It hasn’t changed in quite a >>>> while and I can’t remember the last time it was modified due to changes >>> in >>>> Log4j it has and while continue to change with changes made in Flume >>>> releases. I imagine we have quite a few components that are similar. >>>> >>>> Ralph >>>> >>>>> On Apr 24, 2017, at 8:39 AM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>> >>>>> On Apr 24, 2017 2:38 AM, "Mikael Ståldal" <mikael.stal...@magine.com> >>>> wrote: >>>>> >>>>> I fully agree with Matt's both proposals. >>>>> >>>>> I'm skeptic to creating more repositories (than we already have) >>> though. >>>> I >>>>> think that we should start by splitting out modules from log4j-core and >>>>> keep those modules in the main repository with synchronized versioning >>>> and >>>>> releases, at least for the 2.9 release. We can always move those >>> modules >>>> to >>>>> other repositories later if we want to. >>>>> >>>>> >>>>> I do not like more repos either. Since we have already gone down the >>> more >>>>> modules road, I say we keep going. >>>>> >>>>> Gary >>>>> >>>>> >>>>> It is a lot of administrative work to create a new repository (as we >>> have >>>>> seen for log4j-scala), I don't want us to do all that work over and >>> over >>>>> again unless really necessary. >>>>> >>>>> We have a JIRA ticket for this: >>>>> https://issues.apache.org/jira/browse/LOG4J2-1650 >>>>> >>>>> I have already started by breaking out log4j-server: >>>>> https://issues.apache.org/jira/browse/LOG4J2-1851 >>>>> >>>>> I think the next step is to break out plugins (layouts and appenders) >>>> with >>>>> optional 3rd party dependencies into their own modules. >>>>> >>>>> >>>>>> On Sun, Apr 23, 2017 at 7:45 PM, Matt Sicker <boa...@gmail.com> wrote: >>>>>> >>>>>> I think I brought this topic up like 3 years ago when I was working on >>>>>> initial OSGi support, but now that we have 3 more years worth of code >>>>>> additions and optional features, I think this might be a more >>>> appropriate >>>>>> time to discuss it again in light of experience. >>>>>> >>>>>> Building log4j-core itself already takes a long time, and many plugins >>>>>> aren't updated very often at all. In the past, requiring users to >>> simply >>>>>> add log4j-core plus any transitive dependencies to use optional >>> features >>>>>> seemed to work well enough, but I still think that's a confusing >>>>>> distribution mechanism as demonstrated by the numerous bug reports and >>>>>> Stack Overflow posts regarding missing transitive dependencies for >>>> various >>>>>> features. I spent some time experimenting with Log4j Boot a little >>> while >>>>>> ago to help alleviate this problem, but this may be unnecessary if we >>>> can >>>>>> agree to modularize log4j-core itself. >>>>>> >>>>>> I have two different proposals, both of which can be used at the same >>>>> time. >>>>>> >>>>>> 1. Split out everything from log4j-core that requires 3rd party >>>>>> dependencies (except for AsyncLogger, though perhaps we could consider >>>>>> shading and renaming those classes like some other low level libraries >>>> do >>>>>> with JCTools). Ideally, I'd like to see each module have required >>>>>> dependencies instead of optional ones, so that if, for instance, I >>>> include >>>>>> a "log4j-config-yaml" dependency, I know that Log4j will support YAML >>>>>> configuration without having to specify the individual Jackson >>>>>> dependencies. >>>>>> >>>>>> 2. Split out from log4j-core a sort of log4j-spi module which defines >>>>>> interfaces, abstract classes, and annotations for plugins that would >>> be >>>>>> promoted to the same level of backwards compatibility guarantees as >>>>>> log4j-api. This would aid in cementing what we really wish to maintain >>>>>> compatibility with in the backend while allowing other modules to have >>>>> less >>>>>> strict guarantees. >>>>>> >>>>>> With proposal #1, I'd think that we could more easily start moving >>>> modules >>>>>> into separate repositories and release trains. Without #2, though, >>> this >>>>>> makes version support more annoying to handle, but that's what we'll >>>> face >>>>>> regardless as we separate more repositories. If we go this route, then >>>>>> there will be no need for a Log4j Boot subproject. >>>>>> >>>>>> What do you all think? >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> mikael.stal...@magine.com >>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>> >>>>> Privileged and/or Confidential Information may be contained in this >>>>> message. If you are not the addressee indicated in this message >>>>> (or responsible for delivery of the message to such a person), you may >>>> not >>>>> copy or deliver this message to anyone. In such case, >>>>> you should destroy this message and kindly notify the sender by reply >>>>> email. >>>> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> > >