> On Jan 23, 2018, at 7:29, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > IMO the main repo should contain the stuff 80% (or more) of our user’s use > and the stuff that is common across all plugins. So the file appenders and > console appenders all belong, probably most of the existing lookups and > filters. Since the Syslog Appender probably fits in I would also keep the > socket appenders as well. > > If it was up to me I would move the following Appenders: Cassandra, Flume, > JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB. > In addition to those I would move the taglib, imx-gui and samples modules and > possibly the perf module.
Two questions: 1. How much faster do you estimate this will make the build? 2. How do we verify that changes in log4j-core didn’t break any of the plugins? About the perf module: If you take perf out of the main repo we will only be able to create performance tests against pre-built binaries. This is impractical and the added overhead likely means performance testing becomes too cumbersome for anyone to do it any more. I think that’s a bad idea. > Although it is probably lightly used I would consider keeping the iostreams > module, although to be honest I am not sure why it isn’t part of the api > module. > > Ralph > >> On Jan 22, 2018, at 2:19 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> I'm curious: What is threshold where it would be OK to add stuff to the >> main repo? >> >> Gary >> >> On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> I don’t see why this work would require 3.0 as we aren’t planning on >>> breaking any contracts to do this. >>> >>> As I’ve said, I am not tied to each plugin having its own repo. I am OK >>> with these options; a) each plugin has its own repo and site and is >>> released independently, b) we use the plugins repo and move all the more >>> lightly used components there. It would have its own site, or c) we group >>> plugins by how they are related (RDBMS, NoSQL, “Transport” (Flume or >>> similar) with each having its own site. >>> >>> Obviously I do not consider continuing to add new plugins to the main >>> build as one of the options. >>> >>> Ralph >>> >>>> On Jan 22, 2018, at 12:36 PM, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>> This whole conversation just reminds me of all the times in the past I >>>> suggested full modularization of the core API/SPI. I think such an effort >>>> would make sense in a 3.0 release. >>>> >>>> In 2.x, perhaps what we can do is define a stable plugin API based on >>> what >>>> we already have. Since we're still supporting Java 7, I'd suggest we make >>>> abstract classes be the stable part of the API since we don't have >>> default >>>> methods on interfaces here. >>>> >>>> And yes, the GitBox integration thing sounds neat, particularly for code >>>> review, though that's a separate topic entirely. >>>> >>>> On 22 January 2018 at 00:37, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>> >>>>> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers < >>> ralph.go...@dslextreme.com> >>>>> wrote: >>>>> >>>>>> I am very much against the idea of a single repo. Yes, you can have >>>>>> multiple projects in the repo but I am not sure how that can be sanely >>>>>> released. I much prefer the model that Maven has taken. They are now >>>>> using >>>>>> gitbox [1] which seems to allow GitHub to be the primary repo. >>>>> >>>>> >>>>> GitHub is a distracting tangent here IMO. I really like GitHub's code >>>>> commenting feature, but it should not matter if we use Apache's Git >>> hosted >>>>> repos or GitHub's. So I'm not sure why we are mixing GitHub in the >>>>> conversation... ;-) >>>>> >>>>> Gary >>>>> >>>>> >>>>>> Every Maven plugin is individually released. Scroll down the link below >>>>> to >>>>>> the Maven section and you can see all the plugin repos. >>>>>> >>>>>> The upside to this is that it are: >>>>>> 1. It is far easier to perform releases of the individual >>>>>> components. >>>>>> 2. It is much easier to accept plugin contributions. >>>>>> The downsides are: >>>>>> 1. A page like https://maven.apache.org/plugins/ < >>>>>> https://maven.apache.org/plugins/> is needed to keep track of the >>> plugin >>>>>> versions. >>>>>> 2. It could make sense to have log4j-parent and log4j-bom >>>>>> projects. The first to help keep the builds similar and the second to >>>>> help >>>>>> customers pick up the latest versions. >>>>>> >>>>>> Ralph >>>>>> >>>>>> [1] https://gitbox.apache.org/repos/asf <https://gitbox.apache.org/ >>>>>> repos/asf> >>>>>> >>>>>>> On Jan 21, 2018, at 8:55 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I am writing this to in an effort to understand how we can manage and >>>>>> grow >>>>>>> Log4j. I use the term 'grow' not in the 'bigger is better' sense but >>>>> more >>>>>>> in the maturing sense. >>>>>>> >>>>>>> I am prompted to write this by Ralph's comment that log4j-core and the >>>>>> main >>>>>>> repo is too big and that releases take too long make, partially >>>>> prompted >>>>>> by >>>>>>> my addition of a new module called log4j-jdbc-dbcp2 which currently >>>>>>> contains one small class with a dependency on Apache Commons DBCP 2. >>>>>>> >>>>>>> I would like to express my gratitude at Ralph's efforts to revitalized >>>>>>> Log4j and performing most release management duties. Thank you Ralph! >>>>>>> >>>>>>> I can see two main orthogonal issues: >>>>>>> - The size of the git repo. >>>>>>> - The size of the log4j-core module. >>>>>>> >>>>>>> Ralph has proposed that new modules like log4j-jdbc-dbcp2 be moved to >>>>>>> another 'plugin' repo. >>>>>>> >>>>>>> I really dislike this idea: >>>>>>> - The plugin repo has never been released. Not that one releases a >>> repo >>>>>> but >>>>>>> you get the point. >>>>>>> - How do you keep things in sync between repos and code when we have >>> no >>>>>>> official 'core' SPI. >>>>>>> >>>>>>> For my money, we should keep _everything_ in one repo. Good enough for >>>>>>> Google, so good enough for me. What we release out of that repo is a >>>>>>> different story and what I would like to discuss next. >>>>>>> >>>>>>> This is not the same as Maven plugins IMO but the case could be made >>>>> for >>>>>> it >>>>>>> I suppose where a lot/most plugins live in their own repos. It is not >>>>> the >>>>>>> same as with Maven IMO because our plugins rely on log4j-core and it's >>>>>>> guts, for which we only make loose compatibility guarantees -- as >>>>> opposed >>>>>>> to log4j-core where we are strict(er). Maven OTOH, has a API for >>> plugin >>>>>>> auteurs. >>>>>>> >>>>>>> For example, log4j-jdbc-dbcp2 replies on the guts of log4j-core and we >>>>>> have >>>>>>> no 'official' core SPI, so splitting it off into a separate repo would >>>>>>> greatly increase the risk of it falling out of sync. It is just so >>> much >>>>>>> more easier to maintain when it is all in one repo. >>>>>>> >>>>>>> My proposal is to: >>>>>>> >>>>>>> - Put everything back into one repo (Chainsaw too?) >>>>>>> - Define a core SPI for plugin writers where we make some statement >>>>> about >>>>>>> BC, more than the casual 'we try not break stuff.' >>>>>>> - Defining what Log4j project 'components' we have and release based >>> on >>>>>>> that. For example, today, all of the main Log4j repo is one component >>>>>> with >>>>>>> many modules. Chainsaw would be another component of the Log4j >>> project. >>>>>>> Maybe we need to redefine components: API, File, JDBC and so on. A >>>>>>> component can have one of more module >>>>>>> - Got for there. >>>>>>> >>>>>>> Thoughts? Help me flush this out? >>>>>>> >>>>>>> Thank you for reading! >>>>>>> Gary >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> > >
