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.
