On 22 January 2018 at 16: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. 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. > I like this idea generally since those plugins are rarely updated after being developed. The iostreams API could be added to log4j-api. The actual implementation details of how to go about separating repos, though, seems to be the complicated part. > > 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> > >> > >> > >> > > > -- Matt Sicker <boa...@gmail.com>
