Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Mon, Jan 22, 2018 at 3:26 PM, Mikael Ståldal wrote: > I actually prefer to keep everything related to Log4j 2 (maybe except > Chainsaw) in the same repository, if we can find a way to manage that > properly. > A big +1 from me on that one. The question is how to "manage

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

> On Jan 22, 2018, at 3:20 PM, Gary Gregory wrote: > > On Mon, Jan 22, 2018 at 3:14 PM, Ralph Goers > wrote: > >> I started to read it but it is too long. To be honest I would love it if >> I could just run the release from Jenkins.

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I actually prefer to keep everything related to Log4j 2 (maybe except Chainsaw) in the same repository, if we can find a way to manage that properly. But if we have to split it up as Ralph wants, we should do it properly and have one repository and release train per module (or closely related

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Mon, Jan 22, 2018 at 3:14 PM, Ralph Goers wrote: > I started to read it but it is too long. To be honest I would love it if > I could just run the release from Jenkins. Unfortunately, that would > require someone’s code signing key which would be a bit problematic

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I started to read it but it is too long. To be honest I would love it if I could just run the release from Jenkins. Unfortunately, that would require someone’s code signing key which would be a bit problematic to install on a shared server. In addition, I am a bit paranoid about making sure

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

When performing a release I always run the build a few times. Because it takes so long and because fixing a release that fails halfway through is such a pain I always run the build to make sure it will work before I start the release build, so I could certainly skip the tests when actually

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I read this blog post recently about build tools and found it interesting: < http://www.lihaoyi.com/post/BuildToolsasPureFunctionalPrograms.html>. Perhaps we can lift some ideas from here to find some build optimizations we may have missed (e.g., caching settings). On 22 January 2018 at 14:40,

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Mon, Jan 22, 2018 at 12:26 PM, Matt Sicker wrote: > I still haven't seen a nice way to integrate multiple Maven-generated > websites as it is. If we broke into multiple repositories, we'd have to > basically rewrite the website infrastructure as well (which I've been >

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I still haven't seen a nice way to integrate multiple Maven-generated websites as it is. If we broke into multiple repositories, we'd have to basically rewrite the website infrastructure as well (which I've been thinking about for a while anyways). As a result, either direction we take (monorepo

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

This looks promising: http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html (especially the @NotThreadSafe annotation, potentially in combination with JUnit Suits) On Sun, Jan 21, 2018 at 13:12 Remko Popma wrote: >

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

Yes, I have thought about this. Maven has had separate repos for plugins for years. In every quarterly they have at least a dozen releases. They create the draft quarterly report right after the previous one is submitted and the release manager for each plugin updates the draft as part of the

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

Mikael, Ralph, Have you really thought through the implications of having a separate repository for each module? The overhead is very large! It would mean: * a separate website for each repo (our current Log4j2 website only knows about the modules in the logging-log4j project). * a separate

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I am fine with doing that but we would still want a way to get to all the plugin sites from the log4j web site. Maven does that and maintains a list at https://maven.apache.org/plugins/ . I think the easiest way to manage a page like that would to have it be a

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

As I wrote recently, I don't think that having a kitchen-sink plugins repository is a good way to solve this. Eventually that repository will get too big. It's better to create a new repository for each new module (or possibly for a couple of related modules, but they should be more related

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

JUnit 5 might have something more extensible there, though it does require Java 8 (at least for the test artifacts). I'm not sure either as I've mostly been using other testing frameworks when not using JUnit 4. On 19 January 2018 at 21:19, Remko Popma wrote: > Reducing

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

Reducing the time it takes to run the core tests is key. It would be great if we could specify which tests should be forked, and run the rest non-forked. Perhaps we need to enhance Surefire. Or can JUnit 5 help somehow (haven’t looked at it yet)? Remko (Shameless plug) Every java main()

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

I'd much prefer if we had a leaner core repo for more frequent releases (RERO after all). I've only done the release process a couple times, but Ralph is right: more modules means a larger pain in the ass. The other thing we could really benefit from would be speeding up unit tests. If we can run

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

Gary, I am complaining because I perform the releases. You never have. We keep adding more and more crap to the build and it keeps taking longer and longer. Af far as I am concerned that is a valid technical reason. My -1 stands. Ralph > On Jan 18, 2018, at 10:24 PM, Gary Gregory

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers wrote: > OK, but that doesn’t resolve the initial problem. The log4j 2 project is > too large. > >From what I've experienced, folks complain about the size of the api and core jars, not the Maven project. What is the

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Thu, Jan 18, 2018 at 9:28 PM, Ralph Goers wrote: > -1 > > Please revert and move this to the log4j plugins project. > Hello, I do not see what technical reason this -1 is based on since none have been given. The new module has one class in it with one test that

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

OK, but that doesn’t resolve the initial problem. The log4j 2 project is too large. Ralph > On Jan 18, 2018, at 10:15 PM, Gary Gregory wrote: > > On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers > wrote: > >> In addition, the build is now

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers wrote: > In addition, the build is now failing to compile on Jenkins. > Oops, please accept my apologies. I got caught by the Eclipse compiler being more forgiving (or more powerful) than the Oracle compiler in the

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

In addition, the build is now failing to compile on Jenkins. Ralph > On Jan 18, 2018, at 9:28 PM, Ralph Goers wrote: > > -1 > > Please revert and move this to the log4j plugins project. > > Ralph > >> On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote: >>