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:26:02 GMT
On Mon, Jan 22, 2018 at 2:25 PM, Gary Gregory <garydgregory@gmail.com>
wrote:

>
>
> On Mon, Jan 22, 2018 at 2:21 PM, Gary Gregory <garydgregory@gmail.com>
> wrote:
>
>>
>>
>> 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.
>>>
>>
>> (bit send by accident)
>
> I'm not only worried about that but also ending up with some brittle
> dependency chain like:
>
> log4j-jdbc-dbcp2
>   depends on log4j-jdbc (does not exist yet)
>      depends on log4j-core
>          depends on log4j-api.
>
> Today this works out of the box. Would it become, for example:
>
> log4j-2.11.0-jdbc-dbcp2-1.0
>   depends on log4j-2.11.0-jdbc-1.0 (does not exist yet)
>      depends on log4j-core-2.11.0
>          depends on log4j-api-2.11.0
>
> or would I not bother coding the required Log4j version to get:
>
> log4j-jdbc-dbcp2-1.0
>   depends on log4j-jdbc-1.0 (does not exist yet)
>      depends on log4j-core-2.11.0
>          depends on log4j-api-2.11.0
>

Or maybe I use a matching version:

log4j-jdbc-dbcp2-2.11.0
>   depends on log4j-jdbc-2.11.0 (does not exist yet)
>      depends on log4j-core-2.11.0
>          depends on log4j-api-2.11.0
>
>
?

Gary


>
> ?
>

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

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