On Mon, Jan 22, 2018 at 2:21 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
>
>
> On Mon, Jan 22, 2018 at 12:58 PM, Matt Sicker <boa...@gmail.com> wrote:
>
>> On 22 January 2018 at 13:48, Ralph Goers <ralph.go...@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
?
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 <boa...@gmail.com>
>>
>
>
