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