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:21:44 GMT
On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker <boards@gmail.com> wrote:

> On 22 January 2018 at 13:48, 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.
> >
> I'm referring to something more in line with past proposals of having a
> sort of log4j-core-api or similar which is essentially just the different
> plugin APIs along with the plugin loader API, and log4j-core would contain
> the most commonly used plugins (file, console, meta appenders, filters,
> layouts). This is an orthogonal idea to what we're trying to solve, though.

I'm not only worried about that but also ending up with some brittle
dependency chain like:

depends on log4j-jdbc (does not exist yet) depends on log4j-core depends on
log4j-api. Today this works out of the box.

> > 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.
> >
> If we have separate repos, we'll want a better semantic versioning scheme
> here. I'd imagine we'd need something more enforceable at compile time and
> run time to verify that the version of log4j-core is compatible with the
> plugins in question.
> Also, a question from earlier asked how we can verify the plugins continue
> to work against the latest log4j-core. We can set this up in Jenkins to
> autobuild when upstream dependencies are built. So for example, we can tie
> the sister repos to the main one via snapshots and make Jenkins perform the
> CI on it.
> --
> Matt Sicker <boards@gmail.com>

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