been
> >>> encountered by us.
> >>>
> >>> Ralph
> >>>
> >>>
> >>>
> >>>> On May 17, 2020, at 11:03 AM, Volkan Yazıcı
> >>>> wrote:
> >>>>
> >>>> Maybe a na
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
>>
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 com
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
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
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 Si
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
n 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 wor
ch 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
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://m
> 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 thi
consider moving the existing time-related classes,
> >>>> because
> >>>>>>> that
> >>>>>>> would break client code. These should stay as is:
> >>>>>>> * Clock
> >>>>>>> * NanoClock
> >>>>>&g
gt; * 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 thin
, 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&qu
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.
ctually, 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
>>
.)
> > >
> > > Gary
> > >
> > >>
> > >>
> > >>
> > >> On Wed, Jan 24, 2018 at 11:54 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi,
> >
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.u
is 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, wrote:
>> >
IMO core.util.datetime, should be core.datetime or simply
> > core.util.time.
> >
> > Gary
> >
> > On Wed, Jan 24, 2018 at 4:22 AM, wrote:
> >
> > > Repository: logging-log4j2
> > > Updated Branches:
> > > refs/heads/LOG4J2-1883-instan
an 24, 2018 at 4:22 AM, 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
:
> 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.ap
]
[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
.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 tru
in: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 wou
ly run on Java 7 and not on Travis. I can't
dig in today unfortunately.
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
&
rong. Those Socket option traffic class tests
have failed for various reasons before. I think [~garydgregory] once added
them, so maybe he can investigate them in deep?
> Docker build broken with log4j-api-java9
>
>
>
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.
uote}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 bu
you docker VM has issue to access network,
maybe check windows firewall and/or restart the docker machine.
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org
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:
dows docker machine :
{code}
docker-machine start default
docker-machine env default
docker build .
{code}
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira
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:
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
>
mand 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.apach
----
{code}
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
>
[
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
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
pull request at:
https://github.com/apache/logging-log4j2/pull/84
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
>
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 log
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
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-ap
ssue:
https://github.com/apache/logging-log4j2/pull/84
Can certainly be updated for that since it's not installed via apt-get.
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
>
d on the issue:
https://github.com/apache/logging-log4j2/pull/84
Curious, why not Maven 3.5.0?
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira
jdk9 requirements
Signed-off-by: phymbert
> Docker build broken with log4j-api-java9
>
>
> Key: LOG4J2-1950
> URL: https://issues.apache.org/jira/browse/LOG4J2-1950
> Project: Lo
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
tor 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
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
would be a simpler solution IMO.
>
> On 22 May 2017 at 06:16, Mikael Ståldal wrote:
>
>> IntelliJ IDEA is "smart" enough to automatically pick up the
>> src/main/java9 folder.
>>
>>
>>
>> On 2017-05-21 22:26, Ralph Goers wrote:
>
, Mikael Ståldal 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 abl
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.
Ralp
> 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'
gt;>>
>>> Ralph
>>>
>>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal wrote:
>>>>
>>>> Same with IntelliJ IDEA. You can set JRE per module (such as
log4j-api, log4j-core), but not per source folder.
>>>>
>>>> So this
>>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal 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 enou
erves http://picocli.info
>
>>
>> Ralph
>>
>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal wrote:
>>>
>>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api,
>>> log4j-core), but not per source folder.
>>>
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 on
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
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
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 wrote:
>
> I set the JRE for that project to Java 9. I do not think you can set
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
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 s
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
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
64 matches
Mail list logo
