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 22:07:00 GMT
On Mon, Jan 22, 2018 at 3:03 PM, Scott Deboy <scott.deboy@gmail.com> wrote:

> Correcting my prior comment: the nightmare I was referring to was the
> ugliness we did and un-did related to the never-released receivers and
> 'component' companions.  Definitely feels like deja vu.
>
> https://github.com/apache/log4j-component/blob/trunk/pom.xml
>
> apache-log4j-companions-parent etc etc
>

Hi Scott,

I'm not sure I recall or was around that episode. Would you please mind
telling us what the parallel is here and what you see as the lesson for our
current situation?

Thank you!
Gary

>
>
> On 1/22/18, Matt Sicker <boards@gmail.com> wrote:
> > Using Maven profiles could help, though when tagging a release, if we
> > didn't release every module within, then it'd get out of sync anyways.
> Then
> > it would still require building every single component in each release,
> > even when said components haven't changed at all.
> >
> > On 22 January 2018 at 15:50, Gary Gregory <garydgregory@gmail.com>
> wrote:
> >
> >> Coming back around to the idea of One Repo to Rule Them All*TM* ... what
> >> if
> >> we used Maven profiles to separate out the "main" build from "other"
> >> builds?
> >>
> >> All that is needed to move modules from one build to another is just to
> >> edit the profile!
> >>
> >> 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>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Matt Sicker <boards@gmail.com>
> >
>

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