On Wed, Jan 24, 2018 at 10:05 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Thanks for that Remko. > > We are about due for another Log4j 2 release. I won’t be able to get a > release of log4j-server and then move the plugins to the plugins project in > a short enough time to warrant holding off a Log4j 2 release. So I am going > to say Gary should go ahead and add the mongo3 module for now. I will > imagine it will take a couple of months before I can do the work but I will > let everyone know when I start to work on that. I wouldn’t move anything > out of the main build until the plugins repo is ready for a release. > > FWIW, since it takes me at least 4 hours to perform the release I can’t > guarantee when I will get to it, but I would hope it would be in the next > couple of weeks. > > Does that sound reasonable? > Hello, I'll commit log4j-mongodb3 today. Let's see how the rest plays out... Gary > > Ralph > > > > > > On Jan 24, 2018, at 7:20 PM, Remko Popma <remko.po...@gmail.com> wrote: > > > > I’m still not convinced that moving the items that Ralph enumerated out > of core will make a significant difference in the time it takes to do a > release (I believe other measures will be more effective), but fine. > > > > If Ralph wants this as a precondition to continue to perform the Log4j2 > releases then I can accept that. I’m not planning to start doing the Log4j2 > releases and I’m grateful that others are willing to do so. > > > > However, an important question that needs to be answered before we do > this is: how do we detect when changes in the main Log4j2 project broke one > of the plugins when they live in another repo? > > > > Creating a plugin API is one option but this will take time to design, > develop and test. > > > > One possible alternative: Can we set up a continuous integration service > that builds the main project together with the plugins subproject? (We > probably need this regardless of whether there is a plugin API or not.) I’m > open to other solutions but we do need some process in place to detect > breaking changes. > > > > FYI I strongly feel the perf module should stay in the main project/repo > or it won’t be useable. > > > > Finally, I think breaking up log4j-plugins into many separate repos is > not a good idea. It may sound nice on the surface but the overhead is > large. Are the people pushing for the repo-per-module idea willing to do > the release work for these plugins? And is everyone else willing to review > and vote for 10 plugin releases instead of just one? And integrate 10 > websites instead of one? > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > >> On Jan 25, 2018, at 9:45, Matt Sicker <boa...@gmail.com> wrote: > >> > >> I'm going to sum up my view here: if we split up repos to include > plugins > >> that depend on log4j-core, then we first need to define and release a > >> stable plugin API. If we can't guarantee BC for plugins, then there's no > >> realistic way to both split out additional plugins and have them be > >> officially endorsed plugins. If said plugins were completely outside > Apache > >> (e.g., personal GitHub pages), then it wouldn't be as strict. > >> > >> Also, I find it hard to believe that Google really uses a monorepo > anymore. > >> Such an idea wouldn't work too well with software that isn't > continuously > >> released. > >> > >> I suppose that's an alternative: I'd be open to splitting up repos > however > >> desired if releases were continually published to avoid version number > >> synchronisation efforts, but I'm not so sure how well that meshes with > the > >> Apache Way for releasing software. > > > > >
