logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [log4j] The shape of Log4j
Date Mon, 22 Jan 2018 21:19:43 GMT
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.goers@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 <boards@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 <garydgregory@gmail.com>
> wrote:
> >
> >> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers <
> ralph.goers@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 <garydgregory@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 <boards@gmail.com>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message