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