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:08:40 GMT
On Mon, Jan 22, 2018 at 2:58 PM, 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.
>

That reminds me that just like when I cast a VOTE I try to say what I did
and how. I would be nice if we had a 'build log' the RM would save some
place when putting up an RC.

Gary


>
> 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