The error with the missing artifact happens when you skip tests. The test that 
failed for you never fails for me on OS X but fails randomly in Jenkins.  I’m 
not sure why no one has looked at it yet.

Ralph

> On Aug 3, 2017, at 6:52 AM, Jörn Huxhorn <jhuxh...@googlemail.com> wrote:
> 
> OK, everything works for me with 2.9-SNAPSHOT.
> I can receive JSON, YAML and XML events just fine.
> 
> I had the following error while building:
> [ERROR] Failed to execute goal on project log4j-core-its: Could not resolve 
> dependencies for project 
> org.apache.logging.log4j:log4j-core-its:jar:2.9-SNAPSHOT: Could not find 
> artifact org.apache.logging.log4j:log4j-server:jar:tests:2.9-SNAPSHOT in 
> apache.snapshots (https://repository.apache.org/snapshots), try downloading 
> from https://logging.apache.org/log4j/2.x/download.html -> [Help 1]
> 
> That wasn’t a serious problem for me since I only need API and core.
> But I wanted to inform you about this issue since building log4j worked fine 
> for me just a few days ago.
> 
> I’m sure it worked at d3b722083b8f21ea105a4f01132f08b373cb401e and I think it 
> also worked at b96f5220dbebf6e0a4fb9f7da07c3a9d7d443418
> 
> Cheers,
> Jörn.
> 
> 
> On 3. August 2017 at 13:30:24, Mikael Ståldal (mi...@apache.org) wrote:
>> Yes, that test is known to be unstablle.
>> 
>> Just build with -DskipTests
>> 
>> 
>> On 2017-08-03 11:24, Jörn Huxhorn wrote:
>>> I get test failures building against HEAD 
>>> (3ac727026f295941fe71a34d6c80afc242f38c0f).  
>>> 
>>> Environment:
>>> $ mvn -version
>>> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
>>> 2017-04-03T21:39:06+02:00)  
>>> Maven home: /Users/huxi/.sdkman/candidates/maven/current
>>> Java version: 1.8.0_144, vendor: Oracle Corporation
>>> Java home: 
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre  
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: “mac"
>>> 
>>> Test failure:
>>> -------------------------------------------------------------------------------
>>>   
>>> Test set: 
>>> org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest
>>>   
>>> -------------------------------------------------------------------------------
>>>   
>>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.518 s <<< 
>>> FAILURE!  
>> - in 
>> org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest
>>   
>>> testRollingFileAppenderWithReconfigure(org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest)
>>>   
>> Time elapsed: 2.518 s <<< FAILURE!
>>> java.lang.AssertionError:
>>> 
>>> Expected: is <2>
>>> but: was <3>
>>> at 
>>> org.apache.logging.log4j.core.appender.rolling.RollingAppenderDirectWriteWithReconfigureTest.testRollingFileAppenderWithReconfigure(RollingAppenderDirectWriteWithReconfigureTest.java:68)
>>>   
>>> 
>>> 
>>> 
>>> 
>>> On 2. August 2017 at 11:30:47, Mikael Ståldal (mi...@apache.org) wrote:
>>>> In 2.9-SNAPSHOT, you can use includeNullDelimiter="true" on the layout.
>>>> 
>>>> 
>>>> On 2017-08-02 09:23, Jörn Huxhorn wrote:
>>>>> I started working on the Lilith side of this and I think I’m pretty much 
>>>>> done.
>>>>> 
>>>>> To test the new functionality in a sandbox application, I’d now need the 
>>>>> ability to  
>> switch
>>>> JsonLayout, YamlLayout and XmlLayout into a mode were events are 
>>>> terminated with  
>> a 0-byte
>>>> instead of being separated by “, ".
>>>>> 
>>>>> 
>>>>> On 26. July 2017 at 21:14:41, Mikael Ståldal (mi...@apache.org) wrote:
>>>>>> That would make sense.
>>>>>> 
>>>>>> On 2017-07-26 19:51, Jörn Huxhorn wrote:
>>>>>>> Isn’t this supposed to also use 0-byte terminated events in the future?
>>>>>>> Because in that case it would make sense to change from String to 
>>>>>>> byte[] processing.  
>>>>>>> 
>>>>>>> On 26. July 2017 at 17:49:07, Mikael Ståldal (mi...@apache.org) wrote:
>>>>>>>> They just need the String version:
>>>>>>>> 
>>>>>>>> https://github.com/apache/logging-log4j-tools/blob/master/log4j-server/src/main/java/org/apache/logging/log4j/server/InputStreamLogEventBridge.java#L100
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2017-07-26 17:40, Gary Gregory wrote:
>>>>>>>>> What do our XML and JSON server need? Let's make sure we handle those 
>>>>>>>>> use
>>>>>>>>> cases.
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> On Jul 26, 2017 05:30, "Jörn Huxhorn" wrote:
>>>>>>>>> 
>>>>>>>>>> +1
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 26. July 2017 at 13:29:27, Mikael Ståldal (mi...@apache.org) 
>>>>>>>>>> wrote:
>>>>>>>>>>> Maybe I should remove both the Reader and the InputStream versions,
>>>>>>>>>>> since they cannot parse multiple log events from a stream, and are 
>>>>>>>>>>> thus
>>>>>>>>>>> not very useful.
>>>>>>>>>>> 
>>>>>>>>>>> On 2017-07-26 10:34, Jörn Huxhorn wrote:
>>>>>>>>>>>> It would maybe be a good idea to get rid of the Reader method
>>>>>>>>>> altogether since it mainly
>>>>>>>>>>> introduces an unnecessary point of failure if the Reader is using an
>>>>>>>>>> encoding other than
>>>>>>>>>>> UTF-8.
>>>>>>>>>>>> 
>>>>>>>>>>>> Using a FileReader would be an example for this since its limited
>>>>>>>>>> c'tors are always using
>>>>>>>>>>> Charset.defaultCharset().name().
>>>>>>>>>>>> 
>>>>>>>>>>>> The correct way to create an UTF-8 file reader is the less than
>>>>>>>>>> obvious "new InputStreamReader(new
>>>>>>>>>>> FileInputStream(file), StandardCharsets.UTF_8)”. That’s a very 
>>>>>>>>>>> common  
>>>>>>>>>> mistake.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to