Re: [Log4j] Potential simplification to java9 builds?

gt; >>> encountered by us. > >>> > >>> Ralph > >>> > >>> > >>> > >>>> On May 17, 2020, at 11:03 AM, Volkan Yazıcı > >>>> wrote: > >>>> > >>>> Maybe a naive questi

Re: [Log4j] Potential simplification to java9 builds?

;>> 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 >>>> p

Re: [Log4j] Potential simplification to java9 builds?

gt; > > 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?

Re: [Log4j] Potential simplification to java9 builds?

w 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 p

Re: [Log4j] Potential simplification to java9 builds?

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

Re: [Log4j] Potential simplification to java9 builds?

: > > 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 Sic

Re: [Log4j] Potential simplification to java9 builds?

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

Re: [Log4j] Potential simplification to java9 builds?

gin 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

Re: [Log4j] Potential simplification to java9 builds?

de 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. > >

[Log4j] Potential simplification to java9 builds?

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

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

> 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

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

t; >>>>> > >>>>> > >>>>> > >>>>>> * SystemMillisClock > >>>>>>> > >>>>>>> I would not consider moving the existing time-related classes, > >>>> because > >

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

y as is: >>>>>>> * Clock >>>>>>> * NanoClock >>>>>>> * ClockFactory >>>>>>> * SystemNanoClock, DummyNanoClock >>>>>>> * CachedClock, CoarseCachedClock, SystemClock >>>>>>>

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

>> 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 t

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

>>> > >> 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 t

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

>> 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 &g

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

il" is >> not >> > > nice IMO. In Java 8 we have java.time, not java.util.time, so >> core.time >> > > feels right (and modern.) >> > > >> > > Gary >> > > >> > >> >> > >> >> > &g

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

t; 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 < > gar

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

gt; >> 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 &g

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

.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. >> > >&g

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

til.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-lo

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

t; > 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

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

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 > > > Proj

Re: Log4J2-API-Java9 Build Failure

] [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

Re: Log4J2-API-Java9 Build Failure

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 th

Log4J2-API-Java9 Build Failure

-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

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

}}, 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 -versi

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

}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

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

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/b

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

ken with log4j-api-java9 > > > Key: LOG4J2-1950 > URL: https://issues.apache.org/jira/browse/LOG4J2-1950 > Project: Log4j 2 > Issue Type: Bug > Environment: Docker >

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

. > 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 >

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

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.or

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

-- [INFO] BUILD FAILURE [INFO] [INFO] Total time: 26:20 min [INFO] Finished at: 2017-06-26T18:00:22Z [INFO] Final Memory: 42M/213M [INFO] --

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

[ 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-ja

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

ker 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: Dock

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

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-ja

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

://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 >

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

://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-ja

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

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 > UR

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

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

Re: Java9

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

Re: Java9

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. >> >> >> >>

Re: Java9

, 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 &g

Re: Java9

> 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

Re: Java9

liJ 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.

Re: Java9

od 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, >>>&

Re: Java9

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. >>&g

Re: Java9

; 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

Re: Java9

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

Re: Java9

lease > 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

Re: Java9

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.

Re: Java9

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

Re: Java9

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

Java9

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