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 wrote:
>
>
On Thu, Jan 18, 2018 at 6:05 PM, Matt Sicker wrote:
> I tend to use `git commit --amend` locally to continually update my latest
> commit. It's rare that I resort to an interactive rebase (generally if I've
> somehow managed to screw up a branch's history; just squash it into one
> commit and mov
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 target size/metric if it is curr
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 runs in less
than a second. So
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 failing to compile on Jenkins.
>>
>
> Oops, please acce
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
generics department. All of that des
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:
>>
>> Repository: logging-log4j2
-1
Please revert and move this to the log4j plugins project.
Ralph
> On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote:
>
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master bb6fcd09e -> 639f093b8
>
>
> [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling th
I tend to use `git commit --amend` locally to continually update my latest
commit. It's rare that I resort to an interactive rebase (generally if I've
somehow managed to screw up a branch's history; just squash it into one
commit and move on).
On 16 January 2018 at 22:01, Ralph Goers wrote:
> Se
Since JPMS didn't really add anything useful for module versions, perhaps
our repos outside the main one can indicate their minimum log4j-core/api
versions via the standard OSGi manifest.mf attributes?
On 17 January 2018 at 04:09, Mikael Ståldal wrote:
> Well, that's a decision we have to make.
Doesn’t matter. When the release is performed the release plugin modifies all
the poms. The release manager only needs to know what the version should be.
Having the changes.xml reflect that is a good way to do it.
Ralph
> On Jan 18, 2018, at 9:23 AM, Gary Gregory wrote:
>
> Hi All:
>
> Just
Hi All:
Just FYI: The file changes.xml states 2.11.0 but POMs state 2.10.1
Gary
12 matches
Mail list logo
