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