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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>>> >>>> On Apr 24, 2017 2:38 AM, "Mikael Ståldal" <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: MagineTV] >>>> >>>> *Mikael Ståldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> [email protected] >>>> 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 <[email protected]> >>
