Re: [Log4j] Potential simplification to java9 builds?

[Matt Sicker]

Yeah, the docs are out of date, but this was an ongoing problem from
Java 6 to 7 to 8 to 9.

On Thu, 21 May 2020 at 10:31, Ralph Goers  wrote:
>
> Actually, it was addressed in Java 9 via StackWalker. So the mechanism to 
> walk the stack changed completely between Java 8 and Java 9. I believe 
> obtaining the Process id was also made easier in Java 9.
>
> Ralph
>
> > On May 21, 2020, at 7:53 AM, Matt Sicker  wrote:
> >
> > There are API changes in Java 9+ related to internal classes we needed
> > in previous versions. There's a bit of history behind that documented
> > here: 
> > https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/util/StackLocator.html
> >
> > On Thu, 21 May 2020 at 09:06, Christopher  wrote:
> >>
> >> I'm curious: what is the basis for the multi-release builds in the
> >> first place? Is the code actually different for the two versions or is
> >> it just to address build-related issues?
> >>
> >> On Sun, May 17, 2020 at 4:02 PM Ralph Goers  
> >> wrote:
> >>>
> >>> I kind of doubt it. Logging runs up against this primarily because Oracle 
> >>> dropped support for sun.reflect.Reflection at the same time they added 
> >>> StackWalker. Most everything else had years to switch to a replacement.
> >>>
> >>> https://www.elastic.co/blog/elasticsearch-java-9-and-beyond 
> >>> <https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic 
> >>> only tests against the Java version you have chosen to compile with. They 
> >>> rely on their CI tools to run multiple builds to these the combinations.
> >>>
> >>> I have seen mentions of other components that are delivered as 
> >>> multi-release jars but as far as I can tell Log4j 2 was the first 
> >>> mainstream library to do it so many of the problems with it have been 
> >>> encountered by us.
> >>>
> >>> Ralph
> >>>
> >>>
> >>>
> >>>> On May 17, 2020, at 11:03 AM, Volkan Yazıcı  
> >>>> wrote:
> >>>>
> >>>> Maybe a naive question, but... Does anybody know how other Apache
> >>>> projects deal with this? Do they also require multiple JDKs to be
> >>>> present at compile time? Do they also employ `java9` directory work
> >>>> arounds as in log4j?
> >>>>
> >>>> On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
> >>>>>
> >>>>> I was playing around with the pom a little bit yesterday when I came
> >>>>> across a relatively new maven-compiler-plugin configuration element
> >>>>> called  which can be used to output the compiled
> >>>>> classes relative to META-INF/versions/N rather than the root. This
> >>>>> looks like it would likely remove the need to use
> >>>>> maven-assembly-plugin as an intermediary step.
> >>>>>
> >>>>> I found an interesting approach linked in [1] as the multi-release
> >>>>> parent strategy with source code at [2]. I attempted to refactor
> >>>>> log4j-api to use this pattern, but I couldn't figure out how to make
> >>>>> the same pattern work for test classes (which made it impossible to
> >>>>> compile log4j-api/src/test/java9).
> >>>>>
> >>>>> I'm going to continue experimenting a bit with this, but has anyone
> >>>>> tried out the more recent multi-version tooling support? We were early
> >>>>> users of some things, so I'd imagine tooling has caught up by now.
> >>>>>
> >>>>> [1]: 
> >>>>> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> >>>>> [2]: 
> >>>>> https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> >>>>>
> >>>>> --
> >>>>> Matt Sicker 
> >>>>
> >>>
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>


-- 
Matt Sicker 

Re: [Log4j] Potential simplification to java9 builds?

[Ralph Goers]

Actually, it was addressed in Java 9 via StackWalker. So the mechanism to walk 
the stack changed completely between Java 8 and Java 9. I believe obtaining the 
Process id was also made easier in Java 9.

Ralph

> On May 21, 2020, at 7:53 AM, Matt Sicker  wrote:
> 
> There are API changes in Java 9+ related to internal classes we needed
> in previous versions. There's a bit of history behind that documented
> here: 
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/util/StackLocator.html
> 
> On Thu, 21 May 2020 at 09:06, Christopher  wrote:
>> 
>> I'm curious: what is the basis for the multi-release builds in the
>> first place? Is the code actually different for the two versions or is
>> it just to address build-related issues?
>> 
>> On Sun, May 17, 2020 at 4:02 PM Ralph Goers  
>> wrote:
>>> 
>>> I kind of doubt it. Logging runs up against this primarily because Oracle 
>>> dropped support for sun.reflect.Reflection at the same time they added 
>>> StackWalker. Most everything else had years to switch to a replacement.
>>> 
>>> https://www.elastic.co/blog/elasticsearch-java-9-and-beyond 
>>> <https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic 
>>> only tests against the Java version you have chosen to compile with. They 
>>> rely on their CI tools to run multiple builds to these the combinations.
>>> 
>>> I have seen mentions of other components that are delivered as 
>>> multi-release jars but as far as I can tell Log4j 2 was the first 
>>> mainstream library to do it so many of the problems with it have been 
>>> encountered by us.
>>> 
>>> Ralph
>>> 
>>> 
>>> 
>>>> On May 17, 2020, at 11:03 AM, Volkan Yazıcı  
>>>> wrote:
>>>> 
>>>> Maybe a naive question, but... Does anybody know how other Apache
>>>> projects deal with this? Do they also require multiple JDKs to be
>>>> present at compile time? Do they also employ `java9` directory work
>>>> arounds as in log4j?
>>>> 
>>>> On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
>>>>> 
>>>>> I was playing around with the pom a little bit yesterday when I came
>>>>> across a relatively new maven-compiler-plugin configuration element
>>>>> called  which can be used to output the compiled
>>>>> classes relative to META-INF/versions/N rather than the root. This
>>>>> looks like it would likely remove the need to use
>>>>> maven-assembly-plugin as an intermediary step.
>>>>> 
>>>>> I found an interesting approach linked in [1] as the multi-release
>>>>> parent strategy with source code at [2]. I attempted to refactor
>>>>> log4j-api to use this pattern, but I couldn't figure out how to make
>>>>> the same pattern work for test classes (which made it impossible to
>>>>> compile log4j-api/src/test/java9).
>>>>> 
>>>>> I'm going to continue experimenting a bit with this, but has anyone
>>>>> tried out the more recent multi-version tooling support? We were early
>>>>> users of some things, so I'd imagine tooling has caught up by now.
>>>>> 
>>>>> [1]: 
>>>>> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>>>>> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
>>>>> 
>>>>> --
>>>>> Matt Sicker 
>>>> 
>>> 
> 
> 
> 
> -- 
> Matt Sicker 
> 

Re: [Log4j] Potential simplification to java9 builds?

[Matt Sicker]

There are API changes in Java 9+ related to internal classes we needed
in previous versions. There's a bit of history behind that documented
here: 
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/util/StackLocator.html

On Thu, 21 May 2020 at 09:06, Christopher  wrote:
>
> I'm curious: what is the basis for the multi-release builds in the
> first place? Is the code actually different for the two versions or is
> it just to address build-related issues?
>
> On Sun, May 17, 2020 at 4:02 PM Ralph Goers  
> wrote:
> >
> > I kind of doubt it. Logging runs up against this primarily because Oracle 
> > dropped support for sun.reflect.Reflection at the same time they added 
> > StackWalker. Most everything else had years to switch to a replacement.
> >
> > https://www.elastic.co/blog/elasticsearch-java-9-and-beyond 
> > <https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic 
> > only tests against the Java version you have chosen to compile with. They 
> > rely on their CI tools to run multiple builds to these the combinations.
> >
> > I have seen mentions of other components that are delivered as 
> > multi-release jars but as far as I can tell Log4j 2 was the first 
> > mainstream library to do it so many of the problems with it have been 
> > encountered by us.
> >
> > Ralph
> >
> >
> >
> > > On May 17, 2020, at 11:03 AM, Volkan Yazıcı  
> > > wrote:
> > >
> > > Maybe a naive question, but... Does anybody know how other Apache
> > > projects deal with this? Do they also require multiple JDKs to be
> > > present at compile time? Do they also employ `java9` directory work
> > > arounds as in log4j?
> > >
> > > On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
> > >>
> > >> I was playing around with the pom a little bit yesterday when I came
> > >> across a relatively new maven-compiler-plugin configuration element
> > >> called  which can be used to output the compiled
> > >> classes relative to META-INF/versions/N rather than the root. This
> > >> looks like it would likely remove the need to use
> > >> maven-assembly-plugin as an intermediary step.
> > >>
> > >> I found an interesting approach linked in [1] as the multi-release
> > >> parent strategy with source code at [2]. I attempted to refactor
> > >> log4j-api to use this pattern, but I couldn't figure out how to make
> > >> the same pattern work for test classes (which made it impossible to
> > >> compile log4j-api/src/test/java9).
> > >>
> > >> I'm going to continue experimenting a bit with this, but has anyone
> > >> tried out the more recent multi-version tooling support? We were early
> > >> users of some things, so I'd imagine tooling has caught up by now.
> > >>
> > >> [1]: 
> > >> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> > >> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> > >>
> > >> --
> > >> Matt Sicker 
> > >
> >



-- 
Matt Sicker 

Re: [Log4j] Potential simplification to java9 builds?

[Christopher]

I'm curious: what is the basis for the multi-release builds in the
first place? Is the code actually different for the two versions or is
it just to address build-related issues?

On Sun, May 17, 2020 at 4:02 PM Ralph Goers  wrote:
>
> I kind of doubt it. Logging runs up against this primarily because Oracle 
> dropped support for sun.reflect.Reflection at the same time they added 
> StackWalker. Most everything else had years to switch to a replacement.
>
> https://www.elastic.co/blog/elasticsearch-java-9-and-beyond 
> <https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic only 
> tests against the Java version you have chosen to compile with. They rely on 
> their CI tools to run multiple builds to these the combinations.
>
> I have seen mentions of other components that are delivered as multi-release 
> jars but as far as I can tell Log4j 2 was the first mainstream library to do 
> it so many of the problems with it have been encountered by us.
>
> Ralph
>
>
>
> > On May 17, 2020, at 11:03 AM, Volkan Yazıcı  wrote:
> >
> > Maybe a naive question, but... Does anybody know how other Apache
> > projects deal with this? Do they also require multiple JDKs to be
> > present at compile time? Do they also employ `java9` directory work
> > arounds as in log4j?
> >
> > On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
> >>
> >> I was playing around with the pom a little bit yesterday when I came
> >> across a relatively new maven-compiler-plugin configuration element
> >> called  which can be used to output the compiled
> >> classes relative to META-INF/versions/N rather than the root. This
> >> looks like it would likely remove the need to use
> >> maven-assembly-plugin as an intermediary step.
> >>
> >> I found an interesting approach linked in [1] as the multi-release
> >> parent strategy with source code at [2]. I attempted to refactor
> >> log4j-api to use this pattern, but I couldn't figure out how to make
> >> the same pattern work for test classes (which made it impossible to
> >> compile log4j-api/src/test/java9).
> >>
> >> I'm going to continue experimenting a bit with this, but has anyone
> >> tried out the more recent multi-version tooling support? We were early
> >> users of some things, so I'd imagine tooling has caught up by now.
> >>
> >> [1]: 
> >> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> >> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> >>
> >> --
> >> Matt Sicker 
> >
>

Re: [Log4j] Potential simplification to java9 builds?

[Ralph Goers]

I kind of doubt it. Logging runs up against this primarily because Oracle 
dropped support for sun.reflect.Reflection at the same time they added 
StackWalker. Most everything else had years to switch to a replacement.  

https://www.elastic.co/blog/elasticsearch-java-9-and-beyond 
<https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic only 
tests against the Java version you have chosen to compile with. They rely on 
their CI tools to run multiple builds to these the combinations.

I have seen mentions of other components that are delivered as multi-release 
jars but as far as I can tell Log4j 2 was the first mainstream library to do it 
so many of the problems with it have been encountered by us.

Ralph



> On May 17, 2020, at 11:03 AM, Volkan Yazıcı  wrote:
> 
> Maybe a naive question, but... Does anybody know how other Apache
> projects deal with this? Do they also require multiple JDKs to be
> present at compile time? Do they also employ `java9` directory work
> arounds as in log4j?
> 
> On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
>> 
>> I was playing around with the pom a little bit yesterday when I came
>> across a relatively new maven-compiler-plugin configuration element
>> called  which can be used to output the compiled
>> classes relative to META-INF/versions/N rather than the root. This
>> looks like it would likely remove the need to use
>> maven-assembly-plugin as an intermediary step.
>> 
>> I found an interesting approach linked in [1] as the multi-release
>> parent strategy with source code at [2]. I attempted to refactor
>> log4j-api to use this pattern, but I couldn't figure out how to make
>> the same pattern work for test classes (which made it impossible to
>> compile log4j-api/src/test/java9).
>> 
>> I'm going to continue experimenting a bit with this, but has anyone
>> tried out the more recent multi-version tooling support? We were early
>> users of some things, so I'd imagine tooling has caught up by now.
>> 
>> [1]: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
>> 
>> --
>> Matt Sicker 
> 

Re: [Log4j] Potential simplification to java9 builds?

[Matt Sicker]

Maven and Ant are a couple places that likely needed custom solutions,
but probably not applicable here. Maybe something in Commons? I tried
looking at a few random projects, but I'm not seeing anything. Spring
Framework might have something.

On Sun, 17 May 2020 at 13:03, Volkan Yazıcı  wrote:
>
> Maybe a naive question, but... Does anybody know how other Apache
> projects deal with this? Do they also require multiple JDKs to be
> present at compile time? Do they also employ `java9` directory work
> arounds as in log4j?
>
> On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
> >
> > I was playing around with the pom a little bit yesterday when I came
> > across a relatively new maven-compiler-plugin configuration element
> > called  which can be used to output the compiled
> > classes relative to META-INF/versions/N rather than the root. This
> > looks like it would likely remove the need to use
> > maven-assembly-plugin as an intermediary step.
> >
> > I found an interesting approach linked in [1] as the multi-release
> > parent strategy with source code at [2]. I attempted to refactor
> > log4j-api to use this pattern, but I couldn't figure out how to make
> > the same pattern work for test classes (which made it impossible to
> > compile log4j-api/src/test/java9).
> >
> > I'm going to continue experimenting a bit with this, but has anyone
> > tried out the more recent multi-version tooling support? We were early
> > users of some things, so I'd imagine tooling has caught up by now.
> >
> > [1]: 
> > https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> > [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> >
> > --
> > Matt Sicker 



-- 
Matt Sicker 

Re: [Log4j] Potential simplification to java9 builds?

[Volkan Yazıcı]

Maybe a naive question, but... Does anybody know how other Apache
projects deal with this? Do they also require multiple JDKs to be
present at compile time? Do they also employ `java9` directory work
arounds as in log4j?

On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker  wrote:
>
> I was playing around with the pom a little bit yesterday when I came
> across a relatively new maven-compiler-plugin configuration element
> called  which can be used to output the compiled
> classes relative to META-INF/versions/N rather than the root. This
> looks like it would likely remove the need to use
> maven-assembly-plugin as an intermediary step.
>
> I found an interesting approach linked in [1] as the multi-release
> parent strategy with source code at [2]. I attempted to refactor
> log4j-api to use this pattern, but I couldn't figure out how to make
> the same pattern work for test classes (which made it impossible to
> compile log4j-api/src/test/java9).
>
> I'm going to continue experimenting a bit with this, but has anyone
> tried out the more recent multi-version tooling support? We were early
> users of some things, so I'd imagine tooling has caught up by now.
>
> [1]: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
>
> --
> Matt Sicker 

Re: [Log4j] Potential simplification to java9 builds?

[Matt Sicker]

Yikes, that sounds similar to OSGi. Adding modules makes testing into more
of an integration exercise since traditional JUnit usage assumes a flat
class path.

On Sun, May 17, 2020 at 00:10 Ralph Goers 
wrote:

> I played around with this today. I don’t think it is possible to make the
> tests work.  The reason is that from what I understand the multi-release
> format only works when the classes are packaged in a jar, which hasn’t
> happened when the tests are compiled. This causes the compile to fail since
> it can’t find the Java 9+ classes.
>
> The only way around that would be to package the files in a jar before
> running the tests, which is opposite of what Maven is trying to do.
>
> Ralph
>
> > On Apr 11, 2020, at 9:39 AM, Matt Sicker  wrote:
> >
> > I was playing around with the pom a little bit yesterday when I came
> > across a relatively new maven-compiler-plugin configuration element
> > called  which can be used to output the compiled
> > classes relative to META-INF/versions/N rather than the root. This
> > looks like it would likely remove the need to use
> > maven-assembly-plugin as an intermediary step.
> >
> > I found an interesting approach linked in [1] as the multi-release
> > parent strategy with source code at [2]. I attempted to refactor
> > log4j-api to use this pattern, but I couldn't figure out how to make
> > the same pattern work for test classes (which made it impossible to
> > compile log4j-api/src/test/java9).
> >
> > I'm going to continue experimenting a bit with this, but has anyone
> > tried out the more recent multi-version tooling support? We were early
> > users of some things, so I'd imagine tooling has caught up by now.
> >
> > [1]:
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> > [2]:
> https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> >
> > --
> > Matt Sicker 
> >
>
>
> --
Matt Sicker 

Re: [Log4j] Potential simplification to java9 builds?

[Ralph Goers]

I played around with this today. I don’t think it is possible to make the tests 
work.  The reason is that from what I understand the multi-release format only 
works when the classes are packaged in a jar, which hasn’t happened when the 
tests are compiled. This causes the compile to fail since it can’t find the 
Java 9+ classes.

The only way around that would be to package the files in a jar before running 
the tests, which is opposite of what Maven is trying to do.

Ralph

> On Apr 11, 2020, at 9:39 AM, Matt Sicker  wrote:
> 
> I was playing around with the pom a little bit yesterday when I came
> across a relatively new maven-compiler-plugin configuration element
> called  which can be used to output the compiled
> classes relative to META-INF/versions/N rather than the root. This
> looks like it would likely remove the need to use
> maven-assembly-plugin as an intermediary step.
> 
> I found an interesting approach linked in [1] as the multi-release
> parent strategy with source code at [2]. I attempted to refactor
> log4j-api to use this pattern, but I couldn't figure out how to make
> the same pattern work for test classes (which made it impossible to
> compile log4j-api/src/test/java9).
> 
> I'm going to continue experimenting a bit with this, but has anyone
> tried out the more recent multi-version tooling support? We were early
> users of some things, so I'd imagine tooling has caught up by now.
> 
> [1]: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml
> 
> -- 
> Matt Sicker 
> 

[Log4j] Potential simplification to java9 builds?

[Matt Sicker]

I was playing around with the pom a little bit yesterday when I came
across a relatively new maven-compiler-plugin configuration element
called  which can be used to output the compiled
classes relative to META-INF/versions/N rather than the root. This
looks like it would likely remove the need to use
maven-assembly-plugin as an intermediary step.

I found an interesting approach linked in [1] as the multi-release
parent strategy with source code at [2]. I attempted to refactor
log4j-api to use this pattern, but I couldn't figure out how to make
the same pattern work for test classes (which made it impossible to
compile log4j-api/src/test/java9).

I'm going to continue experimenting a bit with this, but has anyone
tried out the more recent multi-version tooling support? We were early
users of some things, so I'd imagine tooling has caught up by now.

[1]: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
[2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml

-- 
Matt Sicker 

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

[Ralph Goers]

> On Jan 26, 2018, at 8:54 PM, Remko Popma  wrote:
> 
> I guess the classes in util/datetime can be moved to the new time package.
> Note that these are public classes so there is a probability that a user is
> using these classes directly and this move will break their code, but if we
> judge this probability to be low and the argument could be made that these
> classes are private for Log4j2 internal use.
> 
> The same argument could be made for many of the time-related implementation
> classes in util. The interfaces (Clock and NanoClock) are published and
> documented extension points for users to plug into Log4j2. These interfaces
> need to stay in util.
> 
> Perhaps it would be wise to take this opportunity to create two packages:
> core/time and core/time/internal, where everything in the internal package
> should not be directly used by users and is free for us to modify at any
> time.

We definitely should be moving in that direction. Someday we will want to turn 
log4j-core into a “real” Java module. Doing that will require that only 
packages containing classes meant to be public be exported. So moving private 
classes to “private” directories is a step in that direction.

Ralph

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

[Remko Popma]

.
> >>>>
> >>>> On 24 January 2018 at 12:00, Gary Gregory <garydgreg...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <
> garydgreg...@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com
> >
> >>>>>> 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
> >>>>>>>
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I urge you _not_ to name this class Dummy*, that tells me nothing :-(
> >>>>>
> >>>>> OTOH, the Javadoc states:
> >>>>>
> >>>>> /**
> >>>>> * Implementation of the {@code PreciseClock} interface that always
> >>>> returns
> >>>>> a fixed value.
> >>>>> * @since 2.11
> >>>>> */
> >>>>>
> >>>>>
> >>>>> public class DummyPreciseClock implements PreciseClock {
> >>>>>
> >>>>> So I would call this class StaticPreciseClock (or
> >>>> FixedValuePreciseClock,
> >>>>> or ConstantPreciseClock)
> >>>>>
> >>>>> ah... better :-)
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>
> >>>>>> * SystemMillisClock
> >>>>>>>
> >>>>>>> I would not consider moving the existing time-related classes,
> >>>> because
> >>>>>>> that
> >>>>>>> would break client code. These should stay as is:
> >>>>>>> * Clock 
> >>>>>>> * NanoClock 
> >>>>>>> * ClockFactory
> >>>>>>> * SystemNanoClock, DummyNanoClock
> >>>>>>> * CachedClock, CoarseCachedClock, SystemClock
> >>>>>>>
> >>>>>>> I also would not want to rename core.util.datetime; that would just
> >>>>> break
> >>>>>>> client code without any tangible benefit.
> >>>>>>>
> >>>>>>> So, we can add the new 5 classes to core.util.datetime, or create a
> >>>> new
> >>>>>>> package core.util.time and add them there, or leave them in
> >>>> core.util.
> >>>>>>> Not
> >>>>>>> sure which I prefer actually, need to think about it a bit...
> >>>>>>>
> >>>>>>
> >>>>>> For me the right place is core.time. Anything in or under "util" is
> >>>> not
> >>>>>> nice IMO. In Java 8 we have java.time, not java.util.time, so
> >>>> core.time
> >>>>>> feels right (and modern.)
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
> >>>> garydgreg...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> 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
> >&

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

[Ralph Goers]

t; 
>>>>> /**
>>>>> * Implementation of the {@code PreciseClock} interface that always
>>>> returns
>>>>> a fixed value.
>>>>> * @since 2.11
>>>>> */
>>>>> 
>>>>> 
>>>>> public class DummyPreciseClock implements PreciseClock {
>>>>> 
>>>>> So I would call this class StaticPreciseClock (or
>>>> FixedValuePreciseClock,
>>>>> or ConstantPreciseClock)
>>>>> 
>>>>> ah... better :-)
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>> 
>>>>>> * SystemMillisClock
>>>>>>> 
>>>>>>> I would not consider moving the existing time-related classes,
>>>> because
>>>>>>> that
>>>>>>> would break client code. These should stay as is:
>>>>>>> * Clock 
>>>>>>> * NanoClock 
>>>>>>> * ClockFactory
>>>>>>> * SystemNanoClock, DummyNanoClock
>>>>>>> * CachedClock, CoarseCachedClock, SystemClock
>>>>>>> 
>>>>>>> I also would not want to rename core.util.datetime; that would just
>>>>> break
>>>>>>> client code without any tangible benefit.
>>>>>>> 
>>>>>>> So, we can add the new 5 classes to core.util.datetime, or create a
>>>> new
>>>>>>> package core.util.time and add them there, or leave them in
>>>> core.util.
>>>>>>> Not
>>>>>>> sure which I prefer actually, need to think about it a bit...
>>>>>>> 
>>>>>> 
>>>>>> For me the right place is core.time. Anything in or under "util" is
>>>> not
>>>>>> nice IMO. In Java 8 we have java.time, not java.util.time, so
>>>> core.time
>>>>>> feels right (and modern.)
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
>>>> garydgreg...@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> 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, <rpo...@apache.org> wrote:
>>>>>>>> 
>>>>>>>>> Repository: logging-log4j2
>>>>>>>>> Updated Branches:
>>>>>>>>>  refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> LOG4J2-1883 moved SystemMillisClock out of the java9 module into
>>>>> core
>>>>>>> so
>>>>>>>>> it can be used with any supported Java version
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Project:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>>>>>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>>>>>>>>> commit/b8b519e5
>>>>>>>>> Tree:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>>>>>>>> b8b519e5
>>>>>>>>> Diff:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>>>>>>>> b8b519e5
>>>>>>>>> 
>>>>>>>>> Branch: refs/heads/LOG4J2-1883-instant-field
>>>>>>>>> Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
>>>>>>>>> Parents: 3c22d3d
>>>>>>>>> Author: rpopma <rpo...@apache.org>
>>>>>>>>> Authored: Wed Jan 24 20:22:41 2018 +0900
>>>>>>

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

[Remko Popma]

seCachedClock, SystemClock
>>> > >>
>>> > >> I also would not want to rename core.util.datetime; that would just
>>> > break
>>> > >> client code without any tangible benefit.
>>> > >>
>>> > >> So, we can add the new 5 classes to core.util.datetime, or create a
>>> new
>>> > >> package core.util.time and add them there, or leave them in
>>> core.util.
>>> > >> Not
>>> > >> sure which I prefer actually, need to think about it a bit...
>>> > >>
>>> > >
>>> > > For me the right place is core.time. Anything in or under "util" is
>>> not
>>> > > nice IMO. In Java 8 we have java.time, not java.util.time, so
>>> core.time
>>> > > feels right (and modern.)
>>> > >
>>> > > Gary
>>> > >
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
>>> garydgreg...@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > 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, <rpo...@apache.org> wrote:
>>> > >> >
>>> > >> > > Repository: logging-log4j2
>>> > >> > > Updated Branches:
>>> > >> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>>> > >> > >
>>> > >> > >
>>> > >> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into
>>> > core
>>> > >> so
>>> > >> > > it can be used with any supported Java version
>>> > >> > >
>>> > >> > >
>>> > >> > > Project:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> > >> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>>> > >> > > commit/b8b519e5
>>> > >> > > Tree:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>>> > >> > b8b519e5
>>> > >> > > Diff:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>>> > >> > b8b519e5
>>> > >> > >
>>> > >> > > Branch: refs/heads/LOG4J2-1883-instant-field
>>> > >> > > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
>>> > >> > > Parents: 3c22d3d
>>> > >> > > Author: rpopma <rpo...@apache.org>
>>> > >> > > Authored: Wed Jan 24 20:22:41 2018 +0900
>>> > >> > > Committer: rpopma <rpo...@apache.org>
>>> > >> > > Committed: Wed Jan 24 20:22:41 2018 +0900
>>> > >> > >
>>> > >> > > 
>>> > >> --
>>> > >> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>>> > >> > 
>>> > >> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>>> > >> > 
>>> > >> > >  2 files changed, 34 insertions(+), 34 deletions(-)
>>> > >> > > 
>>> > >> --
>>> > >> > >
>>> > >> > >
>>> > >> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>>> > >> > > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
>>> > >> > > log4j/core/util/SystemMillisClock.java
>>> > >> > > 
>>> > >> --
>>> > >> > > diff --git a/log4j-co

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

[Remko Popma]

hem in core.util.
>>> > >> Not
>>> > >> sure which I prefer actually, need to think about it a bit...
>>> > >>
>>> > >
>>> > > For me the right place is core.time. Anything in or under "util" is not
>>> > > nice IMO. In Java 8 we have java.time, not java.util.time, so core.time
>>> > > feels right (and modern.)
>>> > >
>>> > > Gary
>>> > >
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <garydgreg...@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > 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, <rpo...@apache.org> wrote:
>>> > >> >
>>> > >> > > Repository: logging-log4j2
>>> > >> > > Updated Branches:
>>> > >> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>>> > >> > >
>>> > >> > >
>>> > >> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into
>>> > core
>>> > >> so
>>> > >> > > it can be used with any supported Java version
>>> > >> > >
>>> > >> > >
>>> > >> > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> > >> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>>> > >> > > commit/b8b519e5
>>> > >> > > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>>> > >> > b8b519e5
>>> > >> > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>>> > >> > b8b519e5
>>> > >> > >
>>> > >> > > Branch: refs/heads/LOG4J2-1883-instant-field
>>> > >> > > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
>>> > >> > > Parents: 3c22d3d
>>> > >> > > Author: rpopma <rpo...@apache.org>
>>> > >> > > Authored: Wed Jan 24 20:22:41 2018 +0900
>>> > >> > > Committer: rpopma <rpo...@apache.org>
>>> > >> > > Committed: Wed Jan 24 20:22:41 2018 +0900
>>> > >> > >
>>> > >> > > 
>>> > >> --
>>> > >> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>>> > >> > 
>>> > >> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>>> > >> > 
>>> > >> > >  2 files changed, 34 insertions(+), 34 deletions(-)
>>> > >> > > 
>>> > >> --
>>> > >> > >
>>> > >> > >
>>> > >> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>>> > >> > > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
>>> > >> > > log4j/core/util/SystemMillisClock.java
>>> > >> > > 
>>> > >> --
>>> > >> > > diff --git a/log4j-core-java9/src/main/
>>> > java/org/apache/logging/log4j/
>>> > >> > > core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
>>> > >> > > java/org/apache/logging/log4j/core/util/SystemMillisClock.java
>>> > >> > > deleted file mode 100644
>>> > >> > > index f267320..000
>>> > >> > > --- a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
>>> > >> > > core/util/SystemMillisClock.java
>&

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

[Matt Sicker]

Sounds good to me!

On 26 January 2018 at 06:19, Remko Popma <remko.po...@gmail.com> wrote:

> I moved the new precise time-related classes to a new package core.time as
> requested by Gary.
>
> Note that the preexisting time-related classes in util cannot be moved as
> that would break user code.
>
> On Fri, Jan 26, 2018 at 8:59 PM, Remko Popma <remko.po...@gmail.com>
> wrote:
>
> > I renamed DummyPreciseClock to FixedPreciseClock since it is similar to
> > the Java 8 Clock::fixed factory method.
> >
> > On Thu, Jan 25, 2018 at 9:55 AM, Matt Sicker <boa...@gmail.com> wrote:
> >
> >> 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 <garydgreg...@gmail.com>
> wrote:
> >>
> >> > On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <
> garydgreg...@gmail.com>
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > > On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com
> >
> >> > > 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
> >> > >>
> >> > >
> >> > Hi,
> >> >
> >> > I urge you _not_ to name this class Dummy*, that tells me nothing :-(
> >> >
> >> > OTOH, the Javadoc states:
> >> >
> >> > /**
> >> > * Implementation of the {@code PreciseClock} interface that always
> >> returns
> >> > a fixed value.
> >> > * @since 2.11
> >> > */
> >> >
> >> >
> >> > public class DummyPreciseClock implements PreciseClock {
> >> >
> >> > So I would call this class StaticPreciseClock (or
> >> FixedValuePreciseClock,
> >> > or ConstantPreciseClock)
> >> >
> >> > ah... better :-)
> >> >
> >> > Gary
> >> >
> >> >
> >> >
> >> > > * SystemMillisClock
> >> > >>
> >> > >> I would not consider moving the existing time-related classes,
> >> because
> >> > >> that
> >> > >> would break client code. These should stay as is:
> >> > >> * Clock 
> >> > >> * NanoClock 
> >> > >> * ClockFactory
> >> > >> * SystemNanoClock, DummyNanoClock
> >> > >> * CachedClock, CoarseCachedClock, SystemClock
> >> > >>
> >> > >> I also would not want to rename core.util.datetime; that would just
> >> > break
> >> > >> client code without any tangible benefit.
> >> > >>
> >> > >> So, we can add the new 5 classes to core.util.datetime, or create a
> >> new
> >> > >> package core.util.time and add them there, or leave them in
> >> core.util.
> >> > >> Not
> >> > >> sure which I prefer actually, need to think about it a bit...
> >> > >>
> >> > >
> >> > > For me the right place is core.time. Anything in or under "util" is
> >> not
> >> > > nice IMO. In Java 8 we have java.time, not java.util.time, so
> >> core.time
> >> > > feels right (and modern.)
> >> > >
> >> > > Gary
> >> > >
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
> >> garydgreg...@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >> > Hi,
> >> > >> >
> >> > >> > The package core.time is starting to look like a kitchen sink.
> Why
> >> no

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

[Remko Popma]

I moved the new precise time-related classes to a new package core.time as
requested by Gary.

Note that the preexisting time-related classes in util cannot be moved as
that would break user code.

On Fri, Jan 26, 2018 at 8:59 PM, Remko Popma <remko.po...@gmail.com> wrote:

> I renamed DummyPreciseClock to FixedPreciseClock since it is similar to
> the Java 8 Clock::fixed factory method.
>
> On Thu, Jan 25, 2018 at 9:55 AM, Matt Sicker <boa...@gmail.com> wrote:
>
>> 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 <garydgreg...@gmail.com> wrote:
>>
>> > On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <garydgreg...@gmail.com>
>> > wrote:
>> >
>> > >
>> > >
>> > > On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com>
>> > > 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
>> > >>
>> > >
>> > Hi,
>> >
>> > I urge you _not_ to name this class Dummy*, that tells me nothing :-(
>> >
>> > OTOH, the Javadoc states:
>> >
>> > /**
>> > * Implementation of the {@code PreciseClock} interface that always
>> returns
>> > a fixed value.
>> > * @since 2.11
>> > */
>> >
>> >
>> > public class DummyPreciseClock implements PreciseClock {
>> >
>> > So I would call this class StaticPreciseClock (or
>> FixedValuePreciseClock,
>> > or ConstantPreciseClock)
>> >
>> > ah... better :-)
>> >
>> > Gary
>> >
>> >
>> >
>> > > * SystemMillisClock
>> > >>
>> > >> I would not consider moving the existing time-related classes,
>> because
>> > >> that
>> > >> would break client code. These should stay as is:
>> > >> * Clock 
>> > >> * NanoClock 
>> > >> * ClockFactory
>> > >> * SystemNanoClock, DummyNanoClock
>> > >> * CachedClock, CoarseCachedClock, SystemClock
>> > >>
>> > >> I also would not want to rename core.util.datetime; that would just
>> > break
>> > >> client code without any tangible benefit.
>> > >>
>> > >> So, we can add the new 5 classes to core.util.datetime, or create a
>> new
>> > >> package core.util.time and add them there, or leave them in
>> core.util.
>> > >> Not
>> > >> sure which I prefer actually, need to think about it a bit...
>> > >>
>> > >
>> > > For me the right place is core.time. Anything in or under "util" is
>> not
>> > > nice IMO. In Java 8 we have java.time, not java.util.time, so
>> core.time
>> > > feels right (and modern.)
>> > >
>> > > Gary
>> > >
>> > >>
>> > >>
>> > >>
>> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > 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, <rpo...@apache.org> wrote:
>> > >> >
>> > >> > > Repository: logging-log4j2
>> > >> > > Updated Branches:
>> > >> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>> > >> > >
>> > >&

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

[Remko Popma]

I renamed DummyPreciseClock to FixedPreciseClock since it is similar to the
Java 8 Clock::fixed factory method.

On Thu, Jan 25, 2018 at 9:55 AM, Matt Sicker <boa...@gmail.com> wrote:

> 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 <garydgreg...@gmail.com> wrote:
>
> > On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <garydgreg...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com>
> > > 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
> > >>
> > >
> > Hi,
> >
> > I urge you _not_ to name this class Dummy*, that tells me nothing :-(
> >
> > OTOH, the Javadoc states:
> >
> > /**
> > * Implementation of the {@code PreciseClock} interface that always
> returns
> > a fixed value.
> > * @since 2.11
> > */
> >
> >
> > public class DummyPreciseClock implements PreciseClock {
> >
> > So I would call this class StaticPreciseClock (or FixedValuePreciseClock,
> > or ConstantPreciseClock)
> >
> > ah... better :-)
> >
> > Gary
> >
> >
> >
> > > * SystemMillisClock
> > >>
> > >> I would not consider moving the existing time-related classes, because
> > >> that
> > >> would break client code. These should stay as is:
> > >> * Clock 
> > >> * NanoClock 
> > >> * ClockFactory
> > >> * SystemNanoClock, DummyNanoClock
> > >> * CachedClock, CoarseCachedClock, SystemClock
> > >>
> > >> I also would not want to rename core.util.datetime; that would just
> > break
> > >> client code without any tangible benefit.
> > >>
> > >> So, we can add the new 5 classes to core.util.datetime, or create a
> new
> > >> package core.util.time and add them there, or leave them in core.util.
> > >> Not
> > >> sure which I prefer actually, need to think about it a bit...
> > >>
> > >
> > > For me the right place is core.time. Anything in or under "util" is not
> > > nice IMO. In Java 8 we have java.time, not java.util.time, so core.time
> > > feels right (and modern.)
> > >
> > > Gary
> > >
> > >>
> > >>
> > >>
> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > >> wrote:
> > >>
> > >> > 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, <rpo...@apache.org> wrote:
> > >> >
> > >> > > Repository: logging-log4j2
> > >> > > Updated Branches:
> > >> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
> > >> > >
> > >> > >
> > >> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into
> > core
> > >> so
> > >> > > it can be used with any supported Java version
> > >> > >
> > >> > >
> > >> > > Project: http://git-wip-us.apache.org/
> repos/asf/logging-log4j2/repo
> > >> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> > >> > > commit/b8b519e5
> > >> > > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> > >> > b8b519e5
> > >> > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> > >> > b8b519e5

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

[Matt Sicker]

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 <garydgreg...@gmail.com> wrote:

> On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> >
> >
> > On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com>
> > 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
> >>
> >
> Hi,
>
> I urge you _not_ to name this class Dummy*, that tells me nothing :-(
>
> OTOH, the Javadoc states:
>
> /**
> * Implementation of the {@code PreciseClock} interface that always returns
> a fixed value.
> * @since 2.11
> */
>
>
> public class DummyPreciseClock implements PreciseClock {
>
> So I would call this class StaticPreciseClock (or FixedValuePreciseClock,
> or ConstantPreciseClock)
>
> ah... better :-)
>
> Gary
>
>
>
> > * SystemMillisClock
> >>
> >> I would not consider moving the existing time-related classes, because
> >> that
> >> would break client code. These should stay as is:
> >> * Clock 
> >> * NanoClock 
> >> * ClockFactory
> >> * SystemNanoClock, DummyNanoClock
> >> * CachedClock, CoarseCachedClock, SystemClock
> >>
> >> I also would not want to rename core.util.datetime; that would just
> break
> >> client code without any tangible benefit.
> >>
> >> So, we can add the new 5 classes to core.util.datetime, or create a new
> >> package core.util.time and add them there, or leave them in core.util.
> >> Not
> >> sure which I prefer actually, need to think about it a bit...
> >>
> >
> > For me the right place is core.time. Anything in or under "util" is not
> > nice IMO. In Java 8 we have java.time, not java.util.time, so core.time
> > feels right (and modern.)
> >
> > Gary
> >
> >>
> >>
> >>
> >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <garydgreg...@gmail.com>
> >> wrote:
> >>
> >> > 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, <rpo...@apache.org> wrote:
> >> >
> >> > > Repository: logging-log4j2
> >> > > Updated Branches:
> >> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
> >> > >
> >> > >
> >> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into
> core
> >> so
> >> > > it can be used with any supported Java version
> >> > >
> >> > >
> >> > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> >> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> >> > > commit/b8b519e5
> >> > > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> >> > b8b519e5
> >> > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> >> > b8b519e5
> >> > >
> >> > > Branch: refs/heads/LOG4J2-1883-instant-field
> >> > > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
> >> > > Parents: 3c22d3d
> >> > > Author: rpopma <rpo...@apache.org>
> >> > > Authored: Wed Jan 24 20:22:41 2018 +0900
> >> > > Committer: rpopma <rpo...@apache.org>
> >> > > Committed: Wed Jan 24 20:22:41 2018 +0900
> >> > >
> >> > > 
> >> --
> >> > >  .../log4j/core/util/SystemMillisClock.java  | 34
> >> > 
> >> > >  .../log4j/core/util/SystemMillisClock.java  | 

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

[Gary Gregory]

On Wed, Jan 24, 2018 at 10:55 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:

>
>
> On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com>
> 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
>>
>
Hi,

I urge you _not_ to name this class Dummy*, that tells me nothing :-(

OTOH, the Javadoc states:

/**
* Implementation of the {@code PreciseClock} interface that always returns
a fixed value.
* @since 2.11
*/


public class DummyPreciseClock implements PreciseClock {

So I would call this class StaticPreciseClock (or FixedValuePreciseClock,
or ConstantPreciseClock)

ah... better :-)

Gary



> * SystemMillisClock
>>
>> I would not consider moving the existing time-related classes, because
>> that
>> would break client code. These should stay as is:
>> * Clock 
>> * NanoClock 
>> * ClockFactory
>> * SystemNanoClock, DummyNanoClock
>> * CachedClock, CoarseCachedClock, SystemClock
>>
>> I also would not want to rename core.util.datetime; that would just break
>> client code without any tangible benefit.
>>
>> So, we can add the new 5 classes to core.util.datetime, or create a new
>> package core.util.time and add them there, or leave them in core.util.
>> Not
>> sure which I prefer actually, need to think about it a bit...
>>
>
> For me the right place is core.time. Anything in or under "util" is not
> nice IMO. In Java 8 we have java.time, not java.util.time, so core.time
> feels right (and modern.)
>
> Gary
>
>>
>>
>>
>> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>
>> > 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, <rpo...@apache.org> wrote:
>> >
>> > > Repository: logging-log4j2
>> > > Updated Branches:
>> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>> > >
>> > >
>> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into core
>> so
>> > > it can be used with any supported Java version
>> > >
>> > >
>> > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
>> > > commit/b8b519e5
>> > > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
>> > b8b519e5
>> > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
>> > b8b519e5
>> > >
>> > > Branch: refs/heads/LOG4J2-1883-instant-field
>> > > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
>> > > Parents: 3c22d3d
>> > > Author: rpopma <rpo...@apache.org>
>> > > Authored: Wed Jan 24 20:22:41 2018 +0900
>> > > Committer: rpopma <rpo...@apache.org>
>> > > Committed: Wed Jan 24 20:22:41 2018 +0900
>> > >
>> > > 
>> --
>> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>> > 
>> > >  .../log4j/core/util/SystemMillisClock.java  | 34
>> > 
>> > >  2 files changed, 34 insertions(+), 34 deletions(-)
>> > > 
>> --
>> > >
>> > >
>> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
>> > > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
>> > > log4j/core/util/SystemMillisClock.java
>> > > 
>> --
>> > > diff --git a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
>> > > core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
>> > > java/org/apache/logging/log4j/core/util/SystemMillisClock.java
>> > > deleted file mode 100644
>> > > index f267320..000
>> > > --- a

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

[Gary Gregory]

On Wed, Jan 24, 2018 at 8:58 AM, Remko Popma <remko.po...@gmail.com> 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
> * SystemMillisClock
>
> I would not consider moving the existing time-related classes, because that
> would break client code. These should stay as is:
> * Clock 
> * NanoClock 
> * ClockFactory
> * SystemNanoClock, DummyNanoClock
> * CachedClock, CoarseCachedClock, SystemClock
>
> I also would not want to rename core.util.datetime; that would just break
> client code without any tangible benefit.
>
> So, we can add the new 5 classes to core.util.datetime, or create a new
> package core.util.time and add them there, or leave them in core.util.  Not
> sure which I prefer actually, need to think about it a bit...
>

For me the right place is core.time. Anything in or under "util" is not
nice IMO. In Java 8 we have java.time, not java.util.time, so core.time
feels right (and modern.)

Gary

>
>
>
> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> > 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, <rpo...@apache.org> wrote:
> >
> > > Repository: logging-log4j2
> > > Updated Branches:
> > >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
> > >
> > >
> > > LOG4J2-1883 moved SystemMillisClock out of the java9 module into core
> so
> > > it can be used with any supported Java version
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> > > commit/b8b519e5
> > > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> > b8b519e5
> > > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> > b8b519e5
> > >
> > > Branch: refs/heads/LOG4J2-1883-instant-field
> > > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
> > > Parents: 3c22d3d
> > > Author: rpopma <rpo...@apache.org>
> > > Authored: Wed Jan 24 20:22:41 2018 +0900
> > > Committer: rpopma <rpo...@apache.org>
> > > Committed: Wed Jan 24 20:22:41 2018 +0900
> > >
> > > --
> > >  .../log4j/core/util/SystemMillisClock.java  | 34
> > 
> > >  .../log4j/core/util/SystemMillisClock.java  | 34
> > 
> > >  2 files changed, 34 insertions(+), 34 deletions(-)
> > > --
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> > > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
> > > log4j/core/util/SystemMillisClock.java
> > > --
> > > diff --git a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > > core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
> > > java/org/apache/logging/log4j/core/util/SystemMillisClock.java
> > > deleted file mode 100644
> > > index f267320..000
> > > --- a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > > core/util/SystemMillisClock.java
> > > +++ /dev/null
> > > @@ -1,34 +0,0 @@
> > > -/*
> > > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > > - * contributor license agreements. See the NOTICE file distributed
> with
> > > - * this work for additional information regarding copyright ownership.
> > > - * The ASF licenses this file to You under the Apache license, Version
> > 2.0
> > > - * (the "License"); you may not use this file except in compliance
> with
> > > - * the License. You may obtain a copy of the License at
> > > - *
> > > - *  http://www.apache.org/licenses/LICENSE-2.0
> > > - *
> > > - * Unless required by applicable law or agreed to in writing, software
> > > - * distributed under the

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

[Remko Popma]

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-related classes, because that
would break client code. These should stay as is:
* Clock 
* NanoClock 
* ClockFactory
* SystemNanoClock, DummyNanoClock
* CachedClock, CoarseCachedClock, SystemClock

I also would not want to rename core.util.datetime; that would just break
client code without any tangible benefit.

So, we can add the new 5 classes to core.util.datetime, or create a new
package core.util.time and add them there, or leave them in core.util.  Not
sure which I prefer actually, need to think about it a bit...



On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:

> 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, <rpo...@apache.org> wrote:
>
> > Repository: logging-log4j2
> > Updated Branches:
> >   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
> >
> >
> > LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so
> > it can be used with any supported Java version
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> > commit/b8b519e5
> > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/
> b8b519e5
> > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/
> b8b519e5
> >
> > Branch: refs/heads/LOG4J2-1883-instant-field
> > Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
> > Parents: 3c22d3d
> > Author: rpopma <rpo...@apache.org>
> > Authored: Wed Jan 24 20:22:41 2018 +0900
> > Committer: rpopma <rpo...@apache.org>
> > Committed: Wed Jan 24 20:22:41 2018 +0900
> >
> > --
> >  .../log4j/core/util/SystemMillisClock.java  | 34
> 
> >  .../log4j/core/util/SystemMillisClock.java  | 34
> 
> >  2 files changed, 34 insertions(+), 34 deletions(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> > b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
> > log4j/core/util/SystemMillisClock.java
> > --
> > diff --git a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
> > java/org/apache/logging/log4j/core/util/SystemMillisClock.java
> > deleted file mode 100644
> > index f267320..000
> > --- a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> > core/util/SystemMillisClock.java
> > +++ /dev/null
> > @@ -1,34 +0,0 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements. See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache license, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License. You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > - * See the license for the specific language governing permissions and
> > - * limitations under the license.
> > - */
> > -package org.apache.logging.log4j.core.util;
> > -
> > -/**
> > - * Implementation of the {@code Clock} interface that returns the system
> > time in millisecond granularity.
> > - * @since 2.11
> > - */
> > -public final class SystemMillisClock implements Clock {
> > -
> > -/**
> > - * Returns the system time.
> > - * @return the result of calling {@code System.currentTimeMillis()}
> > - */
> > -@Ov

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

[Gary Gregory]

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, <rpo...@apache.org> wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/LOG4J2-1883-instant-field 3c22d3d83 -> b8b519e5b
>
>
> LOG4J2-1883 moved SystemMillisClock out of the java9 module into core so
> it can be used with any supported Java version
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/b8b519e5
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/b8b519e5
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/b8b519e5
>
> Branch: refs/heads/LOG4J2-1883-instant-field
> Commit: b8b519e5b6125ca08545691a631e8b3e0a0e4cd0
> Parents: 3c22d3d
> Author: rpopma <rpo...@apache.org>
> Authored: Wed Jan 24 20:22:41 2018 +0900
> Committer: rpopma <rpo...@apache.org>
> Committed: Wed Jan 24 20:22:41 2018 +0900
>
> --
>  .../log4j/core/util/SystemMillisClock.java  | 34 
>  .../log4j/core/util/SystemMillisClock.java  | 34 
>  2 files changed, 34 insertions(+), 34 deletions(-)
> ------
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> b8b519e5/log4j-core-java9/src/main/java/org/apache/logging/
> log4j/core/util/SystemMillisClock.java
> --
> diff --git a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> core/util/SystemMillisClock.java b/log4j-core-java9/src/main/
> java/org/apache/logging/log4j/core/util/SystemMillisClock.java
> deleted file mode 100644
> index f267320..000
> --- a/log4j-core-java9/src/main/java/org/apache/logging/log4j/
> core/util/SystemMillisClock.java
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one or more
> - * contributor license agreements. See the NOTICE file distributed with
> - * this work for additional information regarding copyright ownership.
> - * The ASF licenses this file to You under the Apache license, Version 2.0
> - * (the "License"); you may not use this file except in compliance with
> - * the License. You may obtain a copy of the License at
> - *
> - *  http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the license for the specific language governing permissions and
> - * limitations under the license.
> - */
> -package org.apache.logging.log4j.core.util;
> -
> -/**
> - * Implementation of the {@code Clock} interface that returns the system
> time in millisecond granularity.
> - * @since 2.11
> - */
> -public final class SystemMillisClock implements Clock {
> -
> -/**
> - * Returns the system time.
> - * @return the result of calling {@code System.currentTimeMillis()}
> - */
> -@Override
> -public long currentTimeMillis() {
> -return System.currentTimeMillis();
> -}
> -
> -}
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> b8b519e5/log4j-core/src/main/java/org/apache/logging/log4j/
> core/util/SystemMillisClock.java
> --
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SystemMillisClock.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> util/SystemMillisClock.java
> new file mode 100644
> index 000..f267320
> --- /dev/null
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> util/SystemMillisClock.java
> @@ -0,0 +1,34 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache license, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by

Re: Log4J2-API-Java9 Build Failure

[kenneth mcfarland]

Maven reports finding the java jdk for 9 but fails. I presume it not is not
an openjdk issue because I basically copied the toolchain-sample-linux.xml
file to my .m2 folder. I am using maven 3.5.

Thank you guys so much!

[INFO]

[INFO] Building Apache Log4j API Java 9 support 2.9-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ log4j-api-java9
---
[INFO] Deleting /home/kenobi/git/logging-log4j2/log4j-api-java9/target
[INFO]
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @
log4j-api-java9 ---
[INFO] Required toolchain: jdk [ version='9' ]
*[INFO] Found matching toolchain for type jdk:
JDK[/usr/lib/jvm/java-9-openjdk-amd64]*
[INFO]
[INFO] --- maven-remote-resources-plugin:1.5:process
(process-resource-bundles) @ log4j-api-java9 ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @
log4j-api-java9 ---
[INFO]
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @
log4j-api-java9 ---
[INFO] Toolchain in maven-compiler-plugin:
JDK[/usr/lib/jvm/java-9-openjdk-amd64]
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/home/kenobi/git/logging-log4j2/log4j-api-java9/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -


*[ERROR] javac: invalid flag: --releaseUsage: javac  use -help for a list of possible options*

[INFO] 1 error
[INFO] -
[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [
4.077 s]
[INFO] Apache Log4j API Java 9 support  FAILURE [
3.117 s]
[INFO] Apache Log4j API ... SKIPPED
[INFO] Apache Log4j Core .. SKIPPED
[INFO] Apache Log4j Core Integration Tests  SKIPPED
[INFO] Apache Log4j 1.x Compatibility API . SKIPPED
[INFO] Apache Log4j SLF4J Binding . SKIPPED
[INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
[INFO] Apache Log4j Commons Logging Bridge  SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j Samples: Configuration  SKIPPED
[INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
[INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
[INFO] Apache Log4j Samples: Scala API  SKIPPED
[INFO] Apache Log4j OSGi .. SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO] Apache Log4j Liquibase Binding . SKIPPED
[INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 10.938 s
[INFO] Finished at: 2017-07-11T16:17:22-07:00
[INFO] Final Memory: 26M/63M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
(default-compile) on project log4j-api-java9: Compilation failure
[ERROR] javac: invalid flag: --release
[ERROR] Usage: javac  
[ERROR] use -help for a list of possible options
[ERROR]
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn  -rf :log4j-api-java9


On Tue, Jul 11, 2017 at 6:09

Re: Log4J2-API-Java9 Build Failure

[Apache]

Somehow your tool chain is not being found. The --release option is only 
available in java 9. When the build runs the compile plugin should tell you 
that it is using the Java 9 tool chain.

Ralph

> On Jul 10, 2017, at 9:51 PM, kenneth mcfarland <kennethpmcfarl...@gmail.com> 
> wrote:
> 
> I am running Ubuntu 16.04.2 LTS AMD 64
> 
> The sole purpose of my laptop is to get this build to work. I've literally
> reformatted my machine just for this project and I'm at my wits end trying
> to figure this out after googling for 2 days.
> 
> I've made sure the POM reflects the correct path to my jdk, and I've
> experimented the oracle early release jdk, openjdk 9. I made the
> toolchains.xml file point t the correct java 9 paths.
> 
> If it doesn't complain about not finding JDK=9, then it fails on this:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
> (default-compile) on project log4j-api-java9: Compilation failure
> [ERROR] javac: invalid flag: --release
> [ERROR] Usage: javac  
> [ERROR] use -help for a list of possible options
> 
> Other modules in the trunk build fine, but I want them all to build the way
> they should. Any advice would be greatly apprecaited!
> 
> Kenneth

Log4J2-API-Java9 Build Failure

[kenneth mcfarland]

I am running Ubuntu 16.04.2 LTS AMD 64

The sole purpose of my laptop is to get this build to work. I've literally
reformatted my machine just for this project and I'm at my wits end trying
to figure this out after googling for 2 days.

I've made sure the POM reflects the correct path to my jdk, and I've
experimented the oracle early release jdk, openjdk 9. I made the
toolchains.xml file point t the correct java 9 paths.

If it doesn't complain about not finding JDK=9, then it fails on this:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
(default-compile) on project log4j-api-java9: Compilation failure
[ERROR] javac: invalid flag: --release
[ERROR] Usage: javac  
[ERROR] use -help for a list of possible options

Other modules in the trunk build fine, but I want them all to build the way
they should. Any advice would be greatly apprecaited!

Kenneth

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Pierrick HYMBERT (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16066485#comment-16066485
 ] 

Pierrick HYMBERT commented on LOG4J2-1950:
--

The docker VM is configured {{FROM openjdk:7-jdk}}, only log4j-api-java9 module 
use the toolchain jdk9.

Confirmed with the following run just after the build:
{code}
RUN java -version && /opt/apache-maven-3.5.0/bin/mvn -version
{code}

That output:
{code}
Step 5/6 : RUN java -version && /opt/apache-maven-3.5.0/bin/mvn -version
 ---> Running in ec253c24e421
java version "1.7.0_131"
OpenJDK Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-2~deb8u1)
OpenJDK 64-Bit Server VM (build 24.131-b00, mixed mode)
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
2017-04-03T19:39:06Z)
Maven home: /opt/apache-maven-3.5.0
Java version: 1.7.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "4.4.52-boot2docker", arch: "amd64", family: "unix"
 ---> 14c3a4c8a028
{code}

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain ty

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[JIRA]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16066445#comment-16066445
 ] 

Mikael Ståldal commented on LOG4J2-1950:


{quote}SecureSocketAppenderSocketOptionsTest.testSocketTrafficClass:127 
expected:<2> but was:<0>
SocketAppenderSocketOptionsTest.testSocketTrafficClass:107 expected:<2> but 
was:<0>{quote}

Those are the tests that only works on Java 7 (not on Java 8 or 9).

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
>

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064443#comment-16064443
 ] 

Gary Gregory commented on LOG4J2-1950:
--

I get failures but later:

{noformat}
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.186 s 
- in org.apache.logging.log4j.core.PropertiesFileConfigTest
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   AsyncAppenderTest.rewriteTest:92 Expected 
org.apache.logging.log4j.core.appender.AsyncAppenderTest rewriteTest This is a 
test, Actual org.apache.logging.log4j.core.appender.AsyncAppenderTest 
rewriteTest Hello world!
[ERROR]   SecureSocketAppenderSocketOptionsTest.testSocketTrafficClass:127 
expected:<2> but was:<0>
[ERROR]   SocketAppenderSocketOptionsTest.testSocketTrafficClass:107 
expected:<2> but was:<0>
[INFO]
[ERROR] Tests run: 1884, Failures: 3, Errors: 0, Skipped: 18
[INFO]
{noformat}

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see 

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063619#comment-16063619
 ] 

Gary Gregory commented on LOG4J2-1950:
--

What is the command you use?

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
> /opt/apache-maven-3.3.9/bin/mvn verify' returned a non-zero code: 1
> {code}
> I have tried to make it working back, but alpine doesnt support openjdk9 till 
> now, so I suggest to revert to the debian image (FROM openjdk:7-jdk).
> First run is slow, as usual with packages, but then it works smoothly.
> Please check and confirm.
> Have fun with docker :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Pierrick HYMBERT (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063617#comment-16063617
 ] 

Pierrick HYMBERT commented on LOG4J2-1950:
--

Yes Windows docker machine just works fine me.

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
> /opt/apache-maven-3.3.9/bin/mvn verify' returned a non-zero code: 1
> {code}
> I hav

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063609#comment-16063609
 ] 

Gary Gregory commented on LOG4J2-1950:
--

Can I run this on the Windows 10 command line assuming I have Docker installed? 
(How?) Or, is our "Dockerfile" specific to Jenkins or Travis-CI?

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
&

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Pierrick HYMBERT (JIRA)]

>

>
[INFO]
[ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [05:10 min]
[INFO] Apache Log4j API Java 9 support  SUCCESS [01:35 min]
[INFO] Apache Log4j API ... SUCCESS [01:59 min]
[INFO] Apache Log4j Core .. SUCCESS [13:23 min]
[INFO] Apache Log4j Core Integration Tests  SUCCESS [01:22 min]
[INFO] Apache Log4j 1.x Compatibility API . FAILURE [  9.119 s]
[INFO] Apache Log4j SLF4J Binding . SKIPPED
[INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
[INFO] Apache Log4j Commons Logging Bridge  SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j Samples: Configuration  SKIPPED
[INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
[INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
[INFO] Apache Log4j Samples: Scala API  SKIPPED
[INFO] Apache Log4j OSGi .. SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO] Apache Log4j Liquibase Binding . SKIPPED
[INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 26:20 min
[INFO] Finished at: 2017-06-26T18:00:22Z
[INFO] Final Memory: 42M/213M
[INFO] ----
{code}

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED

[jira] [Closed] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Pierrick HYMBERT (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierrick HYMBERT closed LOG4J2-1950.


OK, building. Thanks

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
> /opt/apache-maven-3.3.9/bin/mvn verify' returned a non-zero code: 1
> {code}
> I have tried to make it working back, but alpine doesnt support openjdk9 till 
> now, so I suggest to revert to the debian image (FROM openjdk:7-jdk).
> First run is slow, as usual with packages, but then it works smoothly.
> Please check and confirm.
> Have fun with docker :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-1950.
--
   Resolution: Fixed
Fix Version/s: 2.9

In git master. Please verify and close.

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
> Fix For: 2.9
>
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
> /opt/apache-maven-3.3.9/bin/mvn verify' returned a non-zero code: 1
> {code}
> I have tried to ma

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063290#comment-16063290
 ] 

ASF subversion and git services commented on LOG4J2-1950:
-

Commit 3f45368597b8d47c4997963a4ecc5ae66f486a95 in logging-log4j2's branch 
refs/heads/master from [~phymbert]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=3f45368 ]

[LOG4J2-1950] Fix docker build with jdk9 requirements. Closes #84.

> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> ----
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060650#comment-16060650
 ] 

ASF GitHub Bot commented on LOG4J2-1950:


Github user phymbert commented on the issue:

https://github.com/apache/logging-log4j2/pull/84
  
Updated to 3.5.0, please check


> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> ----
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The command '/bin/sh -c set -ex && cd /src && 
> /opt/apache-maven-3.3.9/bin/mvn verify' returned

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059771#comment-16059771
 ] 

ASF GitHub Bot commented on LOG4J2-1950:


Github user phymbert commented on the issue:

https://github.com/apache/logging-log4j2/pull/84
  
I tried to minimise changes, I would prefer to install mvn as a package 
rather to freeze the version. I may do it tom if you are fine with it. 


> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> ----
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> project log4j-api-java9: Cannot find matching toolchain definitions for the 
> following toolchain types:
> [ERROR] jdk [ version='9' ]
> [ERROR] Please make sure you define the required toolchains in your 
> ~/.m2/toolchains.xml file.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :log4j-api-java9
> The comman

[jira] [Commented] (LOG4J2-1950) Docker build broken with log4j-api-java9

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059547#comment-16059547
 ] 

ASF GitHub Bot commented on LOG4J2-1950:


GitHub user phymbert opened a pull request:

https://github.com/apache/logging-log4j2/pull/84

[LOG4J2-1950] Fix docker build with jdk9 requirements

Revert docker image base from openjdk:7-alpine to openjdk:7-jdk (debian) 
since yet alpine does not include jdk9.
Install jdk9 and specify toolchains file in the mvn build

Signed-off-by: phymbert <pierrick.hymb...@gmail.com>

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/phymbert/logging-log4j2 LOG4J2-1950

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/84.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #84


commit 516e2ab45ec01021098bfef8f55d7748f16c018b
Author: phymbert <pierrick.hymb...@gmail.com>
Date:   2017-06-22T15:33:32Z

[LOG4J2-1950] Fix docker build with jdk9 requirements

Signed-off-by: phymbert <pierrick.hymb...@gmail.com>




> Docker build broken with log4j-api-java9
> 
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Docker
>Reporter: Pierrick HYMBERT
>Priority: Trivial
>
> Since introduction of jdk9 requirement in the build, docker image cannot be 
> built.
> It fails with:
> {code}
> [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 
> ---
> [INFO] Required toolchain: jdk [ version='9' ]
> [ERROR] No toolchain found for type jdk
> [ERROR] Cannot find matching toolchain definitions for the following 
> toolchain types:
> jdk [ version='9' ]
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [05:27 
> min]
> [INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 
> s]
> [INFO] Apache Log4j API ... SKIPPED
> [INFO] Apache Log4j Core .. SKIPPED
> [INFO] Apache Log4j Core Integration Tests  SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge  SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration  SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
> [INFO] Apache Log4j Samples: Scala API  SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 08:47 min
> [INFO] Finished at: 2017-06-22T15:27:35+00:00
> [INFO] Final Memory: 33M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
> projec

[jira] [Created] (LOG4J2-1950) Docker build broken with log4j-api-java9

[Pierrick HYMBERT (JIRA)]

Pierrick HYMBERT created LOG4J2-1950:


 Summary: Docker build broken with log4j-api-java9
 Key: LOG4J2-1950
 URL: https://issues.apache.org/jira/browse/LOG4J2-1950
 Project: Log4j 2
  Issue Type: Bug
 Environment: Docker
Reporter: Pierrick HYMBERT
Priority: Trivial


Since introduction of jdk9 requirement in the build, docker image cannot be 
built.

It fails with:
{code}
[INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ log4j-api-java9 ---
[INFO] Required toolchain: jdk [ version='9' ]
[ERROR] No toolchain found for type jdk
[ERROR] Cannot find matching toolchain definitions for the following toolchain 
types:
jdk [ version='9' ]
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [05:27 min]
[INFO] Apache Log4j API Java 9 support  FAILURE [ 25.103 s]
[INFO] Apache Log4j API ... SKIPPED
[INFO] Apache Log4j Core .. SKIPPED
[INFO] Apache Log4j Core Integration Tests  SKIPPED
[INFO] Apache Log4j 1.x Compatibility API . SKIPPED
[INFO] Apache Log4j SLF4J Binding . SKIPPED
[INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
[INFO] Apache Log4j Commons Logging Bridge  SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j Samples: Configuration  SKIPPED
[INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
[INFO] Apache Log4j Scala 2.11 wrapper for Log4j API .. SKIPPED
[INFO] Apache Log4j Samples: Scala API  SKIPPED
[INFO] Apache Log4j OSGi .. SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO] Apache Log4j Liquibase Binding . SKIPPED
[INFO] Apache Log4j Scala 2.10 wrapper for Log4j API .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 08:47 min
[INFO] Finished at: 2017-06-22T15:27:35+00:00
[INFO] Final Memory: 33M/81M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-toolchains-plugin:1.1:toolchain (default) on 
project log4j-api-java9: Cannot find matching toolchain definitions for the 
following toolchain types:
[ERROR] jdk [ version='9' ]
[ERROR] Please make sure you define the required toolchains in your 
~/.m2/toolchains.xml file.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :log4j-api-java9
The command '/bin/sh -c set -ex && cd /src && 
/opt/apache-maven-3.3.9/bin/mvn verify' returned a non-zero code: 1

{code}

I have tried to make it working back, but alpine doesnt support openjdk9 till 
now, so I suggest to revert to the debian image (FROM openjdk:7-jdk).
First run is slow, as usual with packages, but then it works smoothly.

Please check and confirm.
Have fun with docker :-)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Java9

[Remko Popma]

One idea: we could move (actually copy) the StackLocator interface to the
Java 9 module.
This allows us to build the Java 9 module first. Then, when building the
log4j-api module, the Java 9 classes can be shaded into the log4j-api jar
(excluding StackLocator since we want to compile that interface with Java
7).

That way all modules depend on Java 7 except the log4j-api-java9 module
which depends on Java 9. This is clean, works well in IDEs and does not
require the toolchain workaround. The whole project could probably be
compiled with just JDK 9 this way.

Started to play with this but could not finish today. Need to continue
tomorrow.


On Tue, May 23, 2017 at 12:59 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> Java 9 now has a —release option which should help. However, if we set it
> to Java 7 I suspect the build will fail on the Java 9 stuff even though we
> are using the Java 9 compiler. I really don’t see a way to do this except
> by calling the compiler multiple times.
>
> Ralph
>
> > On May 22, 2017, at 8:49 AM, Matt Sicker <boa...@gmail.com> wrote:
> >
> > I still want to see a better Maven plugin for handling Java 9
> multi-release
> > jars and things like that. The whole Java 9 build is still rather hacky.
> If
> > the entire project was buildable in Java 9 and could still target 7, 8,
> and
> > 9, then that would be a simpler solution IMO.
> >
> > On 22 May 2017 at 06:16, Mikael Ståldal <mi...@apache.org> wrote:
> >
> >> IntelliJ IDEA is "smart" enough to automatically pick up the
> >> src/main/java9 folder.
> >>
> >>
> >>
> >> On 2017-05-21 22:26, Ralph Goers wrote:
> >>
> >>> Since src/main/java9 isn’t normally considered a source directory you
> >>> should be able to work with Java 7 as well. It will just ignore the
> Java 9
> >>> files.
> >>>
> >>> Ralph
> >>>
> >>> On May 21, 2017, at 5:50 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >>>>
> >>>> I set the JRE for that project to Java 9. I do not think you can set
> the
> >>>> JRE per source folder, only per project.
> >>>>
> >>>> Gary
> >>>>
> >>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
> >>>> wrote:
> >>>>
> >>>> I’ve modified the build to put the Java 9 classes of the API into a
> >>>> separate source directory. Can you see if that helps things in
> Eclipse?
> >>>>
> >>>> Ralph
> >>>>
> >>>
> >>>
> >>
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
>
>
>

Re: Java9

[Ralph Goers]

Java 9 now has a —release option which should help. However, if we set it to 
Java 7 I suspect the build will fail on the Java 9 stuff even though we are 
using the Java 9 compiler. I really don’t see a way to do this except by 
calling the compiler multiple times.

Ralph

> On May 22, 2017, at 8:49 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I still want to see a better Maven plugin for handling Java 9 multi-release
> jars and things like that. The whole Java 9 build is still rather hacky. If
> the entire project was buildable in Java 9 and could still target 7, 8, and
> 9, then that would be a simpler solution IMO.
> 
> On 22 May 2017 at 06:16, Mikael Ståldal <mi...@apache.org> wrote:
> 
>> IntelliJ IDEA is "smart" enough to automatically pick up the
>> src/main/java9 folder.
>> 
>> 
>> 
>> On 2017-05-21 22:26, Ralph Goers wrote:
>> 
>>> Since src/main/java9 isn’t normally considered a source directory you
>>> should be able to work with Java 7 as well. It will just ignore the Java 9
>>> files.
>>> 
>>> Ralph
>>> 
>>> On May 21, 2017, at 5:50 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>> 
>>>> I set the JRE for that project to Java 9. I do not think you can set the
>>>> JRE per source folder, only per project.
>>>> 
>>>> Gary
>>>> 
>>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
>>>> wrote:
>>>> 
>>>> I’ve modified the build to put the Java 9 classes of the API into a
>>>> separate source directory. Can you see if that helps things in Eclipse?
>>>> 
>>>> Ralph
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>

Re: Java9

[Matt Sicker]

I still want to see a better Maven plugin for handling Java 9 multi-release
jars and things like that. The whole Java 9 build is still rather hacky. If
the entire project was buildable in Java 9 and could still target 7, 8, and
9, then that would be a simpler solution IMO.

On 22 May 2017 at 06:16, Mikael Ståldal <mi...@apache.org> wrote:

> IntelliJ IDEA is "smart" enough to automatically pick up the
> src/main/java9 folder.
>
>
>
> On 2017-05-21 22:26, Ralph Goers wrote:
>
>> Since src/main/java9 isn’t normally considered a source directory you
>> should be able to work with Java 7 as well. It will just ignore the Java 9
>> files.
>>
>> Ralph
>>
>> On May 21, 2017, at 5:50 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>
>>> I set the JRE for that project to Java 9. I do not think you can set the
>>> JRE per source folder, only per project.
>>>
>>> Gary
>>>
>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
>>> wrote:
>>>
>>> I’ve modified the build to put the Java 9 classes of the API into a
>>> separate source directory. Can you see if that helps things in Eclipse?
>>>
>>> Ralph
>>>
>>
>>
>


-- 
Matt Sicker <boa...@gmail.com>

Re: Java9

[Ralph Goers]

> On May 21, 2017, at 7:32 PM, Remko Popma  wrote:
> 
> 
>> On May 22, 2017, at 8:57, Ralph Goers  wrote:
>> 
>> When you run the release plugin the artifact is deployed when the module 
>> gets to the deploy phase. Thus any shading would take place too late to do 
>> any good.
> 
> I think there's a misunderstanding: the shade plugin is bound to the package 
> phase, not the deploy phase. So the Java 9 classes would be copied in time 
> (before verify>install>deploy). 
> 
> Would you object to the Java 9 classes going to a separate module if we can 
> get this to work?

No, I did not misunderstand. The Java 9 module has to be built after log4j-api 
as it is dependent on the StackLocator interface. The shading has to be 
completed before the log4j-api is deployed. If you can tell me how you can 
resolve that I’m happy to listen.

Ralph

Re: Java9

[Gary Gregory]

On May 21, 2017 7:32 PM, "Remko Popma" <remko.po...@gmail.com> wrote:


> On May 22, 2017, at 8:57, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> When you run the release plugin the artifact is deployed when the module
gets to the deploy phase. Thus any shading would take place too late to do
any good.

I think there's a misunderstanding: the shade plugin is bound to the
package phase, not the deploy phase. So the Java 9 classes would be copied
in time (before verify>install>deploy).

Would you object to the Java 9 classes going to a separate module if we can
get this to work?


Feels more hacky to me. There is no clean solution for now. Why not just
let it be for now? Until the next modules vote at least?

Gary



> It could be done if we renamed log4j-api to something else and then
disable the deploy in the module. Then the new log4j-api could create the
jar.  But this all seems messier than what is there now. If you ignore the
Java 9 stuff it should just work in the IDE.
>
> Ralph
>
>> On May 21, 2017, at 4:50 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>
>>
>>> On May 22, 2017, at 5:30, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
>>>
>>> I’m not sure how to make it be any better than this. Although the Java
9 classes could be removed we would just have to put them back in a couple
of months when Java 9 is released. Putting them in a separate module is not
a great option as that will require an additional jar to run in Java 9.
>>
>> Putting the Java 9 classes in a separate module has several advantages.
It would allow IDE's to function in a standard way. It would also make very
clear which JDKs are required to build the project and remove the need for
the toolchain workaround.
>>
>> Together these make the project more approachable for new contributors
which I feel is important for the long term of the project.
>>
>> What remains is a matter of convincing Maven to do what we need:
>> * we _don't_ want this new module to result in a separate artifact in
the distribution. Seems doable: we already do this with log4j-perf.
>> * we _do_ want the Java 9 classes to be included in the log4j-api
artifact. I hope we can do this with maven-shade?
>>
>> Does this make sense?
>>
>> Remko
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>>
>>> Ralph
>>>
>>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal <mik...@staldal.nu> wrote:
>>>>
>>>> Same with IntelliJ IDEA. You can set JRE per module (such as
log4j-api, log4j-core), but not per source folder.
>>>>
>>>> So this is not enough to fix it. But it is better than nothing, so
please keep it. And do the same for tests if/when we add any tests for the
code in src/main/java9.
>>>>
>>>> I am now able to continue to work with the project in IntelliJ IDEA by
excluding src/main/java9. (But if I work with the Java 9 stuff, I only have
a text editor with syntax highlighting, no other IDE support for that part.)
>>>>
>>>>
>>>>> On 2017-05-21 14:50, Gary Gregory wrote:
>>>>> I set the JRE for that project to Java 9. I do not think you can set
the
>>>>> JRE per source folder, only per project.
>>>>> Gary
>>>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
wrote:
>>>>> I’ve modified the build to put the Java 9 classes of the API into a
>>>>> separate source directory. Can you see if that helps things in
Eclipse?
>>>>> Ralph
>>>
>>>
>>
>
>

Re: Java9

[Remko Popma]

> On May 22, 2017, at 8:57, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> When you run the release plugin the artifact is deployed when the module gets 
> to the deploy phase. Thus any shading would take place too late to do any 
> good.

I think there's a misunderstanding: the shade plugin is bound to the package 
phase, not the deploy phase. So the Java 9 classes would be copied in time 
(before verify>install>deploy). 

Would you object to the Java 9 classes going to a separate module if we can get 
this to work?


> It could be done if we renamed log4j-api to something else and then disable 
> the deploy in the module. Then the new log4j-api could create the jar.  But 
> this all seems messier than what is there now. If you ignore the Java 9 stuff 
> it should just work in the IDE.
> 
> Ralph
> 
>> On May 21, 2017, at 4:50 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> 
>> 
>>> On May 22, 2017, at 5:30, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> 
>>> I’m not sure how to make it be any better than this. Although the Java 9 
>>> classes could be removed we would just have to put them back in a couple of 
>>> months when Java 9 is released. Putting them in a separate module is not a 
>>> great option as that will require an additional jar to run in Java 9.
>> 
>> Putting the Java 9 classes in a separate module has several advantages. It 
>> would allow IDE's to function in a standard way. It would also make very 
>> clear which JDKs are required to build the project and remove the need for 
>> the toolchain workaround. 
>> 
>> Together these make the project more approachable for new contributors which 
>> I feel is important for the long term of the project. 
>> 
>> What remains is a matter of convincing Maven to do what we need:
>> * we _don't_ want this new module to result in a separate artifact in the 
>> distribution. Seems doable: we already do this with log4j-perf. 
>> * we _do_ want the Java 9 classes to be included in the log4j-api artifact. 
>> I hope we can do this with maven-shade?
>> 
>> Does this make sense?
>> 
>> Remko 
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> 
>>> Ralph
>>> 
>>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal <mik...@staldal.nu> wrote:
>>>> 
>>>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
>>>> log4j-core), but not per source folder.
>>>> 
>>>> So this is not enough to fix it. But it is better than nothing, so please 
>>>> keep it. And do the same for tests if/when we add any tests for the code 
>>>> in src/main/java9.
>>>> 
>>>> I am now able to continue to work with the project in IntelliJ IDEA by 
>>>> excluding src/main/java9. (But if I work with the Java 9 stuff, I only 
>>>> have a text editor with syntax highlighting, no other IDE support for that 
>>>> part.)
>>>> 
>>>> 
>>>>> On 2017-05-21 14:50, Gary Gregory wrote:
>>>>> I set the JRE for that project to Java 9. I do not think you can set the
>>>>> JRE per source folder, only per project.
>>>>> Gary
>>>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
>>>>> I’ve modified the build to put the Java 9 classes of the API into a
>>>>> separate source directory. Can you see if that helps things in Eclipse?
>>>>> Ralph
>>> 
>>> 
>> 
> 
> 

Re: Java9

[Ralph Goers]

When you run the release plugin the artifact is deployed when the module gets 
to the deploy phase. Thus any shading would take place too late to do any good. 
It could be done if we renamed log4j-api to something else and then disable the 
deploy in the module. Then the new log4j-api could create the jar.  But this 
all seems messier than what is there now. If you ignore the Java 9 stuff it 
should just work in the IDE.

Ralph

> On May 21, 2017, at 4:50 PM, Remko Popma <remko.po...@gmail.com> wrote:
> 
> 
>> On May 22, 2017, at 5:30, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>> I’m not sure how to make it be any better than this. Although the Java 9 
>> classes could be removed we would just have to put them back in a couple of 
>> months when Java 9 is released. Putting them in a separate module is not a 
>> great option as that will require an additional jar to run in Java 9.
> 
> Putting the Java 9 classes in a separate module has several advantages. It 
> would allow IDE's to function in a standard way. It would also make very 
> clear which JDKs are required to build the project and remove the need for 
> the toolchain workaround. 
> 
> Together these make the project more approachable for new contributors which 
> I feel is important for the long term of the project. 
> 
> What remains is a matter of convincing Maven to do what we need:
> * we _don't_ want this new module to result in a separate artifact in the 
> distribution. Seems doable: we already do this with log4j-perf. 
> * we _do_ want the Java 9 classes to be included in the log4j-api artifact. I 
> hope we can do this with maven-shade?
> 
> Does this make sense?
> 
> Remko 
> 
> (Shameless plug) Every java main() method deserves http://picocli.info
> 
>> 
>> Ralph
>> 
>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal <mik...@staldal.nu> wrote:
>>> 
>>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
>>> log4j-core), but not per source folder.
>>> 
>>> So this is not enough to fix it. But it is better than nothing, so please 
>>> keep it. And do the same for tests if/when we add any tests for the code in 
>>> src/main/java9.
>>> 
>>> I am now able to continue to work with the project in IntelliJ IDEA by 
>>> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have 
>>> a text editor with syntax highlighting, no other IDE support for that part.)
>>> 
>>> 
>>>> On 2017-05-21 14:50, Gary Gregory wrote:
>>>> I set the JRE for that project to Java 9. I do not think you can set the
>>>> JRE per source folder, only per project.
>>>> Gary
>>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
>>>> I’ve modified the build to put the Java 9 classes of the API into a
>>>> separate source directory. Can you see if that helps things in Eclipse?
>>>> Ralph
>> 
>> 
> 

Re: Java9

[Remko Popma]

> On May 22, 2017, at 5:30, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I’m not sure how to make it be any better than this. Although the Java 9 
> classes could be removed we would just have to put them back in a couple of 
> months when Java 9 is released. Putting them in a separate module is not a 
> great option as that will require an additional jar to run in Java 9.

Putting the Java 9 classes in a separate module has several advantages. It 
would allow IDE's to function in a standard way. It would also make very clear 
which JDKs are required to build the project and remove the need for the 
toolchain workaround. 

Together these make the project more approachable for new contributors which I 
feel is important for the long term of the project. 

What remains is a matter of convincing Maven to do what we need:
* we _don't_ want this new module to result in a separate artifact in the 
distribution. Seems doable: we already do this with log4j-perf. 
* we _do_ want the Java 9 classes to be included in the log4j-api artifact. I 
hope we can do this with maven-shade?

Does this make sense?

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> 
> Ralph
> 
>> On May 21, 2017, at 1:14 PM, Mikael Ståldal <mik...@staldal.nu> wrote:
>> 
>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
>> log4j-core), but not per source folder.
>> 
>> So this is not enough to fix it. But it is better than nothing, so please 
>> keep it. And do the same for tests if/when we add any tests for the code in 
>> src/main/java9.
>> 
>> I am now able to continue to work with the project in IntelliJ IDEA by 
>> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have 
>> a text editor with syntax highlighting, no other IDE support for that part.)
>> 
>> 
>>> On 2017-05-21 14:50, Gary Gregory wrote:
>>> I set the JRE for that project to Java 9. I do not think you can set the
>>> JRE per source folder, only per project.
>>> Gary
>>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
>>> I’ve modified the build to put the Java 9 classes of the API into a
>>> separate source directory. Can you see if that helps things in Eclipse?
>>> Ralph
> 
> 

Re: Java9

[Gary Gregory]

In Eclipse Oxygen with the Java 9 beta support addon, I setup the log4j-api
project with Java 9 and Java 7 as the target and it works. I have not
checked with the latest Java9 folder though.

We are on the bleeding edge for sure here.

The only part that is not great is that we require Java 9 to be installed
to build. Us that still the case with the new Java 9 folder set up?

This is all good experience anyway. I just want us to keep the release
trains coming knowing our busy schedules. I am slightly worried that we
could be supporting the Jira tickets coming in but that's how life is in an
open source project.

Gary

On May 21, 2017 1:27 PM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:

> Since src/main/java9 isn’t normally considered a source directory you
> should be able to work with Java 7 as well. It will just ignore the Java 9
> files.
>
> Ralph
>
> > On May 21, 2017, at 5:50 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >
> > I set the JRE for that project to Java 9. I do not think you can set the
> > JRE per source folder, only per project.
> >
> > Gary
> >
> > On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
> wrote:
> >
> > I’ve modified the build to put the Java 9 classes of the API into a
> > separate source directory. Can you see if that helps things in Eclipse?
> >
> > Ralph
>
>
>

Re: Java9

[Ralph Goers]

I’m not sure how to make it be any better than this. Although the Java 9 
classes could be removed we would just have to put them back in a couple of 
months when Java 9 is released. Putting them in a separate module is not a 
great option as that will require an additional jar to run in Java 9.

Ralph

> On May 21, 2017, at 1:14 PM, Mikael Ståldal <mik...@staldal.nu> wrote:
> 
> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
> log4j-core), but not per source folder.
> 
> So this is not enough to fix it. But it is better than nothing, so please 
> keep it. And do the same for tests if/when we add any tests for the code in 
> src/main/java9.
> 
> I am now able to continue to work with the project in IntelliJ IDEA by 
> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have a 
> text editor with syntax highlighting, no other IDE support for that part.)
> 
> 
> On 2017-05-21 14:50, Gary Gregory wrote:
>> I set the JRE for that project to Java 9. I do not think you can set the
>> JRE per source folder, only per project.
>> Gary
>> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
>> I’ve modified the build to put the Java 9 classes of the API into a
>> separate source directory. Can you see if that helps things in Eclipse?
>> Ralph
> 

Re: Java9

[Ralph Goers]

Since src/main/java9 isn’t normally considered a source directory you should be 
able to work with Java 7 as well. It will just ignore the Java 9 files.

Ralph

> On May 21, 2017, at 5:50 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> I set the JRE for that project to Java 9. I do not think you can set the
> JRE per source folder, only per project.
> 
> Gary
> 
> On May 21, 2017 1:29 AM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
> 
> I’ve modified the build to put the Java 9 classes of the API into a
> separate source directory. Can you see if that helps things in Eclipse?
> 
> Ralph

Re: Java9

[Mikael Ståldal]

We need to fix this very soon. It is not acceptable to have the project 
master branch in a state which breaks both of the two most popular Java 
IDEs.


In IntelliJ I now get stuck at com.sun.tools.jconsole.JConsolePlugin not 
found in log4j-jmx-gui.


If we cannot fix this in a timely manner, I suggest we move the 
StackWalker thing into a branch and remove it from master for the time 
being.



On 2017-05-21 14:50, Gary Gregory wrote:

I set the JRE for that project to Java 9. I do not think you can set the
JRE per source folder, only per project.

Gary

On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:

I’ve modified the build to put the Java 9 classes of the API into a
separate source directory. Can you see if that helps things in Eclipse?

Ralph

Re: Java9

[Gary Gregory]

I set the JRE for that project to Java 9. I do not think you can set the
JRE per source folder, only per project.

Gary

On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:

I’ve modified the build to put the Java 9 classes of the API into a
separate source directory. Can you see if that helps things in Eclipse?

Ralph

Java9

[Ralph Goers]

I’ve modified the build to put the Java 9 classes of the API into a separate 
source directory. Can you see if that helps things in Eclipse?

Ralph