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