Re: [log4j] The shape of Log4j

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 mo

Re: [log4j] The shape of Log4j

+1 The added complexity of managing the various repo builds and compatibility outweighs the build-time related cost of adding this code to core, easily. Just consider the time required to RM these other repos. There is no savings here to be found. Scott On Jan 24, 2018 6:20 PM, "Remko Popma" w

Re: [log4j] The shape of Log4j

If you're interested in reading about how Google uses their monorepo, they have a paper you can read through: https://research.google.com/pubs/pub45424.html It's not clear to me reading the paper if they do this for all of their projects(including public repos on github) or just in-house code; it

Re: [log4j] The shape of Log4j

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

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

Aren't the classes in datetime copied from commons? Might be simpler to keep that package uncluttered for easier updates. Also, I like the name ConstantClock or something like that. Constant is a nice term with appropriate mathematical connotations. On 24 January 2018 at 12:00, Gary Gregory wrot

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc2

So far so good with this vote. I'll finish the release process tomorrow morning (approximately 15 hours from the time of this email) if there are no showstopper before then. On 22 January 2018 at 17:08, Remko Popma wrote: > +1 > > (Shameless plug) Every java main() method deserves http://picocli

Re: [log4j] The shape of Log4j

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 end

Re: [log4j] The shape of Log4j

> On Jan 24, 2018, at 3:02 PM, Gary Gregory wrote: > > On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers > > wrote: > >> >> >>> On Jan 24, 2018, at 1:56 PM, Gary Gregory >> wrote: >>> >>> On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers >> >>> wrote: >>> A

Re: [log4j] The shape of Log4j

On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers wrote: > > > > On Jan 24, 2018, at 1:56 PM, Gary Gregory > wrote: > > > > On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers > > > wrote: > > > >> A vote can’t override a veto of a code commit. > >> > > > > I'm trying to get things to move along toward som

Re: [log4j] The shape of Log4j

On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers wrote: > > > > On Jan 24, 2018, at 1:56 PM, Gary Gregory > wrote: > > > > On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers > > > wrote: > > > >> A vote can’t override a veto of a code commit. > >> > > > > I'm trying to get things to move along toward som

Re: [log4j] The shape of Log4j

They are not really orthogonal. 1. Log4j core contains some stuff that isn’t really “core” functionality., such as Kafka or JMS. These cause the core tests to take longer than necessary. 2. The size of the repo directly effects how long a build takes to run, as does the number of components in c

Re: [log4j] The shape of Log4j

> On Jan 24, 2018, at 1:56 PM, Gary Gregory wrote: > > On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers > wrote: > >> A vote can’t override a veto of a code commit. >> > > I'm trying to get things to move along toward some kind of workable > solution we can all live with. Why are you talking ab

Re: [log4j] The shape of Log4j

Yes, and it's unfortunate that they get conflated. On 2018-01-21 16:55, Gary Gregory wrote: I can see two main orthogonal issues: - The size of the git repo. - The size of the log4j-core module.

Re: [log4j] The shape of Log4j

Yes, neither Git nor Maven is optimal for mono-repos since you can only tag/branch the whole repo, and only have one version for the whole build. Google have a big mono-repo, but they do not use Git, nor Maven. I think we should release and version everything in one repo together, otherwise it

Re: [log4j] The shape of Log4j

On Wed, Jan 24, 2018 at 2:15 PM, Mikael Ståldal wrote: > On 2018-01-22 23:37, Matt Sicker wrote: > >> On 22 January 2018 at 16:29, Ralph Goers >> wrote: >> >>> >>> If it was up to me I would move the following Appenders: Cassandra, >>> Flume, >>> JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/

Re: [log4j] The shape of Log4j

On 2018-01-22 23:37, Matt Sicker wrote: On 22 January 2018 at 16:29, Ralph Goers wrote: If it was up to me I would move the following Appenders: Cassandra, Flume, JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB. In addition to those I would move the taglib, imx-gui an

Re: [log4j] The shape of Log4j

On Wed, Jan 24, 2018 at 1:27 PM, Ralph Goers wrote: > You left off two of the other options: > 1. A repo for related plugins. > 2. A repo for each plugin. > > I am open to any option where these plugins are not included in the main > repo. It sounds like the only option you are open to is includi

Re: [log4j] The shape of Log4j

On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers wrote: > A vote can’t override a veto of a code commit. > I'm trying to get things to move along toward some kind of workable solution we can all live with. Why are you talking about procedure? It just feels obstructionist :-( Gary > Ralph > > > On

Re: [log4j] The shape of Log4j

You left off two of the other options: 1. A repo for related plugins. 2. A repo for each plugin. I am open to any option where these plugins are not included in the main repo. It sounds like the only option you are open to is including them in the main repo. Ralph > On Jan 24, 2018, at 1:00 PM

Re: [log4j] The shape of Log4j

A vote can’t override a veto of a code commit. Ralph > On Jan 24, 2018, at 1:00 PM, Gary Gregory wrote: > > I really feel like we're not getting anywhere here :-( > > I have a log4j-mongodb3 appender ready to commit and nowhere to put it. The > empty repo/kitchen-sink/dumping-grounds log4j-plu

Re: [log4j] The shape of Log4j

I really feel like we're not getting anywhere here :-( I have a log4j-mongodb3 appender ready to commit and nowhere to put it. The empty repo/kitchen-sink/dumping-grounds log4j-plugins is not acceptable to me. Ralph does not want it in the main repo. I say it's fine. Now what? Should I call a V

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory wrote: > > > On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma > wrote: > >> I see what you mean. Hmm... >> >> FYI, this feature (LOG4J2-1883) adds the following classes. I added them >> to >> core.util, but they could still be moved to another package:

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma wrote: > I see what you mean. Hmm... > > FYI, this feature (LOG4J2-1883) adds the following classes. I added them to > core.util, but they could still be moved to another package: > * Instant > * PreciseClock > * MutableInstant > * DummyPreciseClock

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

I see what you mean. Hmm... FYI, this feature (LOG4J2-1883) adds the following classes. I added them to core.util, but they could still be moved to another package: * Instant * PreciseClock * MutableInstant * DummyPreciseClock * SystemMillisClock I would not consider moving the existing time-re

Re: logging-log4j2 git commit: LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so it can be used with any supported Java version

Hi, The package core.time is starting to look like a kitchen sink. Why not put this new class into the existing core.util.datetime or into a new core.time package. IMO core.util.datetime, should be core.datetime or simply core.util.time. Gary On Wed, Jan 24, 2018 at 4:22 AM, wrote: > Repositor