Guten Tag Robert Middleton,
am Mittwoch, 15. Juli 2020 um 23:44 schrieben Sie:
> No, I used the release_prepare.sh to generate it, since it's my
> understanding that is the script that should do that.
It is, that means the site is not part of the release anymore after
removing the ANT-parts and i
FWIW, that test should probably be updated to stop statically linking to
the internal class since it was eventually removed from the JDK (made
invisible at least).
On Wed, Jul 15, 2020 at 15:45 Kirk Lund wrote:
> Setting JAVA_HOME to my 1.8 jdk fixed the problem for me. Thank you ck!
>
> PS: My
> How did you create those archives? I guess you didn't use the created
> release_*-scripts, but "make dist dist-zip" again?
No, I used the release_prepare.sh to generate it, since it's my
understanding that is the script that should do that.
I'm not sure if the autotools still work at this point
Setting JAVA_HOME to my 1.8 jdk fixed the problem for me. Thank you ck!
PS: My toolchains.xml defines valid paths to jdk 1.7, jdk 1.8, and jdk 9.
Thanks Ralph!
On Wed, Jul 15, 2020 at 12:51 PM Carter Kozak wrote:
> I ran into a similar issue earlier and resolved it by setting my JAVA_HOME
> to
FWIW, here is mine. I use symlinks to point to the versioned number that is
actually installed for each JDK.
jdk
1.7
sun
/Library/Java/JavaVirtualMachines/java7/Contents/Home
jdk
1.8
sun
/Library/Java/Jav
You must have a toolchains.xml that has both Java 8 and Java 9 or above.
Ralph
> On Jul 15, 2020, at 12:50 PM, Carter Kozak wrote:
>
> I ran into a similar issue earlier and resolved it by setting my JAVA_HOME to
> match my java 1.8 jdk from my toolchains.xml:
> export JAVA_HOME=/usr/lib/jvm/j
I ran into a similar issue earlier and resolved it by setting my JAVA_HOME to
match my java 1.8 jdk from my toolchains.xml:
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
On Wed, Jul 15, 2020, at 15:43, Kirk Lund wrote:
> I'm trying to build 2.13.1 from sources using either JDK 8 or 9 on Mac
I'm trying to build 2.13.1 from sources using either JDK 8 or 9 on Mac OS
but it keeps failing with:
/Users/klund/dev/logging-log4j2 [518]$ mvn
install
...
[*INFO*]
**
[*INFO*] *BUILD FAILURE*
[*INFO*]
*
We can’t “backport” the code from Java 13 as that is licensed under the GPL.
What I was suggesting (without saying it) was that maybe we don’t need the
eventDelimiter parameter. Yes, this should be solved across the board so
everything is consistent.
Ralph
> On Jul 15, 2020, at 12:53 AM, Volk
I found ctest at target/dependency/cmake/bin but when I run it I get
No tests were found!!!
I don’t see a directory named “package” so I am assuming you meant something
else.
Ralph
> On Jul 14, 2020, at 11:56 PM, Stephen Webb wrote:
>
> Could you re-run that test by typing
>
> ctest -R str
Thanks, I hadn’t seen that page.
Ralph
> On Jul 15, 2020, at 1:28 AM, Thorsten Schöning wrote:
>
> Guten Tag Ralph Goers,
> am Mittwoch, 15. Juli 2020 um 08:36 schrieben Sie:
>
>> [...]That said, I don’t see anyplace on the log4cxx web site that
>> even states what platforms it supports.[...]
On Wed, Jul 15, 2020 at 10:06 AM Volkan Yazıcı wrote:
>
> The reason I wanted to go with a simple `String type` field is to keep
> the impact surface and backward compatibility issues at the bay.
>
> I am in favor of `KeyValuePair` -- `KeyValuePair` feels like
> an engineering overkill for our usa
Guten Tag Stephen Webb,
am Mittwoch, 15. Juli 2020 um 05:54 schrieben Sie:
> Thorsten did not accept my pull request.
> https://github.com/apache/logging-log4cxx/pull/18
And I still won't, the necessary tools to make them succeed can easily
be provided for Windows as well:
> C:\Program Files (x8
Guten Tag Robert Middleton,
am Mittwoch, 15. Juli 2020 um 04:16 schrieben Sie:
> As of this point, do the zip/tar.gz files contain everything required for
> release? Is there anything that needs to be added? I want to try and help
> if there's something that's missing.
How did you create those
Guten Tag Ralph Goers,
am Mittwoch, 15. Juli 2020 um 08:36 schrieben Sie:
> [...]That said, I don’t see anyplace on the log4cxx web site that
> even states what platforms it supports.[...]
There's the following table, which at least gives some hints. Besides
that, we shouldn't start a new discuss
The reason I wanted to go with a simple `String type` field is to keep
the impact surface and backward compatibility issues at the bay.
I am in favor of `KeyValuePair` -- `KeyValuePair` feels like
an engineering overkill for our usages. That said, this translates to
368 occurrences of `KeyValuePai
First let me state that this "how to pass escape characters to plugin
parameters of type string from different configuration sources"
problem applies to every other plugin, e.g.,
`AbstractJacksonLayout.Builder#endOfLine`. Hence, nothing specific to
`JsonTemplateLayout`.
That said, I share your hes
After adding that directory to the path as well as the corresponding apr-util
directory I was able to get the build to run. Everything successfully compiled
but I got 1 test failure.
Start 19: streamtestcase
19/60 Test #19: streamtestcase .***Exception: SegFault
2
18 matches
Mail list logo
