I was wondering about that and figured it had something to do with Java 8.
Thanks for fixing it!
On 16 July 2017 at 17:37, Ralph Goers wrote:
> There is an error saying Jenkins doesn’t support Java 7 any for running
> Maven and that toolchains has to be used to compile and test using Java 7.
>
>
There is an error saying Jenkins doesn’t support Java 7 any for running Maven
and that toolchains has to be used to compile and test using Java 7.
The fix for this is to configure the Jenkins job to use Java 8 by default and
to use the Java 7 toolchain when a system property is set. I’ve done th
I didn't on that computer yet as I had just installed Java 9 for the first
time on it this morning.
On 16 July 2017 at 13:10, Ralph Goers wrote:
> If you set the default JAVA_HOME how did the java 9 install override it?
>
> Ralph
>
> > On Jul 16, 2017, at 9:28 AM, Matt Sicker wrote:
> >
> > Nor
If you set the default JAVA_HOME how did the java 9 install override it?
Ralph
> On Jul 16, 2017, at 9:28 AM, Matt Sicker wrote:
>
> Normally I set my default JAVA_HOME to 1.8 since 1.9 hasn't been compatible
> with everything. Otherwise, I'll manually override JAVA_HOME on projects
> that requ
Normally I set my default JAVA_HOME to 1.8 since 1.9 hasn't been compatible
with everything. Otherwise, I'll manually override JAVA_HOME on projects
that require an earlier version.
On 16 July 2017 at 11:25, Ralph Goers wrote:
> How are you configuring your environment? I set my path and JAVA_HO
How are you configuring your environment? I set my path and JAVA_HOME in
/etc/profile. The Java installs never mess with that so the only “default” Java
I have ever seen is the one I have configured.
Ralph
> On Jul 16, 2017, at 9:20 AM, Matt Sicker wrote:
>
> Now that I'm trying this new buil
Now that I'm trying this new build style out for the first time, I've got
some notes:
1. After installing Java 9, it's set to be the default JAVA_HOME if you
don't have one set. Maven has some JAXB-related missing module errors
currently (could be a plugin, could be Maven itself), so make sure to
Hello Ralph, noted and thanks, apologies I have no mac to test with.
Le sam. 15 juil. 2017 à 05:51, Ralph Goers a
écrit :
> OK - I have verified that FileAppenderPermissionsTest is flawed on OS X.
> It is reading /etc/groups to find a group for the user. If it doesn’t find
> a group then it trie
OK - I have verified that FileAppenderPermissionsTest is flawed on OS X. It is
reading /etc/groups to find a group for the user. If it doesn’t find a group
then it tries to use the user’s name - which doesn’t work because there is no
group with that name. On MacOS /etc/groups is only used in sin
Yes. I did that to the rolling tests but I don't know whether the tests are bad
for the permission stuff or whether the functionality doesn't work on MacOS, in
which case it would need to be disabled.
Ralph
> On Jul 14, 2017, at 8:01 AM, Gary Gregory wrote:
>
> I assume you will be adding JUn
I assume you will be adding JUnit Assume calls to skip these tests?
Gary
On Jul 14, 2017 00:01, "Ralph Goers" wrote:
> After ignoring the test causing the previous problem I am now encountering
> errors with the new permissions test. I am disabling the
> RollingAppenderDirect test since it also
After ignoring the test causing the previous problem I am now encountering
errors with the new permissions test. I am disabling the RollingAppenderDirect
test since it also will have the same problem with FileWatcher, but I don’t
know the cause of the other failures.
Ralph
ERROR] Failures:
[E
12 matches
Mail list logo
