Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Binaries in runtime and Frameworks will not be signed directly using
user provided certificate.
- libapplauncher.dylib will be signed with user
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Error mentioned in bug report was due to missing Xcode when running
SetFile. Fixed by not running SetFile if Xcode is not available. This
tool used
We're mostly in agreement.
(Also, I'm not actually an ldap reviewer.)
On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo wrote:
> I agree that this example [1] looks readable (depending on a reader, of
> course). I think it looks readable mostly because it is very explicit.
> However, in a domain
SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the
description or simply remove notice about shortcuts.
Did you omit adding shortcuts to LinuxDebBundler.java on purpose?
- Alexey
On 9/11/2019 9:07 PM, Andy Herrick wrote:
Please review the jpackage
Looks good.
On 9/11/2019 6:07 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
This fix:
1.) adds the new option --linux-shortcut, and now only creates a
shortcut on linux
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
This fix:
1.) adds the new option --linux-shortcut, and now only creates a
shortcut on linux if specified
2.) only creates a shortcut on windows if
Martin,
> On 10 Sep 2019, at 17:40, Martin Buchholz wrote:
>
> Here's a canonical example of an "expected timeout" test that seems natural
> and readable to me.
> timeoutMillis() returns 12ms, adjusted by timeout factor. Ldap might need a
> bigger value.
>
>
> /**
> * timed await
Looks good.
Thanks for the alternative investigations, Roger
On 9/11/19 12:58 PM, Brian Burkhalter wrote:
Although I rather like [1] it is probably too expensive to use a lambda just to
increment the line number. Therefore I am proposing to modify [2] to replace
the AtomicBoolean with a
Although I rather like [1] it is probably too expensive to use a lambda just to
increment the line number. Therefore I am proposing to modify [2] to replace
the AtomicBoolean with a boolean[] as in [3].
Thanks,
Brian
[1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/
[2]
> On 11 Sep 2019, at 16:55, Alan Bateman wrote:
>
> I don't think the jndi-dns docs page is in the jdk repo.
Could you kindly point me to the location of the current jndi-dns docs page? I
can't seem to be able to even find anything related to that on the web. You
might want to try to use your
Thanks Jim,
no worries time wise.
Cheers
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leon...@uk.ibm.com
From: Jim Laskey
To: Andrew Leonard
Cc: core-libs-dev@openjdk.java.net
Date: 10/09/2019 19:05
Subject:
On 11/09/2019 16:16, Pavel Rappo wrote:
On 11 Sep 2019, at 16:10, Alan Bateman wrote:
I assume extending the timeout to TCP will require at least some minimal
updates to the descriptions.
Which descriptions do you have in mind? I cannot seem to find that text
anywhere in the current repo
> On 11 Sep 2019, at 16:10, Alan Bateman wrote:
>
> I assume extending the timeout to TCP will require at least some minimal
> updates to the descriptions.
Which descriptions do you have in mind? I cannot seem to find that text
anywhere in the current repo (jdk/jdk)
$ hg tip
changeset:
On 11/09/2019 15:56, Pavel Rappo wrote:
Sure, from
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html:
"Each lookup is initially performed using UDP. If the response is too long to be
returned in a UDP packet without being truncated, the lookup is repeated using TCP."
Hi Heiko,
Thank you for giving a try to jpackage and for your feedback!
Please find comments inlined.
On 9/10/2019 4:55 AM, Heiko Wagner wrote:
I am sending this feedback as suggested by the jpackage project
(https://jdk.java.net/jpackage/). I hope this is considered helpful
information.
I
Sure, from
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html:
"Each lookup is initially performed using UDP. If the response is too long to
be returned in a UDP packet without being truncated, the lookup is repeated
using TCP."
and
On 09/09/2019 16:06, Martin Buchholz wrote:
:
Another round of stress testing at Google allowed us to fix a handful of
very rare test failures.
8227235: rare failures in testForkHelpQuiesce tck tests
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html
+1
On 9/11/19 8:48 AM, Stephen Colebourne wrote:
+1
On Wed, 11 Sep 2019 at 13:38, wrote:
Hi Stephen,
I confirmed that issuing parseStrict() was irrelevant. The incorrect
text won't throw the exception in "lenient" mode as well. In addition,
"builder" is always instantiated in
On 11/09/2019 13:26, Pavel Rappo wrote:
I'm happy with the overall changeset. I have (once again) made some tiny
changes, you can see them here:
http://cr.openjdk.java.net/~prappo/8228580/webrev.02/
If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s)
are okay
Hi Pavel
Your changes look good to me.
On Wed, 11 Sep 2019 at 14:26, Pavel Rappo wrote:
>
> I'm happy with the overall changeset. I have (once again) made some tiny
> changes, you can see them here:
>
> http://cr.openjdk.java.net/~prappo/8228580/webrev.02/
>
> If you are okay with them,
+1
On Wed, 11 Sep 2019 at 13:38, wrote:
>
> Hi Stephen,
>
> I confirmed that issuing parseStrict() was irrelevant. The incorrect
> text won't throw the exception in "lenient" mode as well. In addition,
> "builder" is always instantiated in AbstractTestPrinterParser on each
> TestNG invocation
Hi Stephen,
I confirmed that issuing parseStrict() was irrelevant. The incorrect
text won't throw the exception in "lenient" mode as well. In addition,
"builder" is always instantiated in AbstractTestPrinterParser on each
TestNG invocation and "strict" is the default mode. Thus I did not
The current algorithm for determining the default timezone on (non-AIX)
unix systems goes something like :
1. If TZ environment variable is defined, use it
2. else if /etc/timezone exists, use the value contained within it
3. else if /etc/localtime exists and is a symbolic link, use the name
The bug references parseStrict() but the test does not. Is the builder
already set to parseStrict() ? Anyway, if the bug is to be clearly
squished, parseStrict() should appear somewhere.
Stephen
On Tue, 10 Sep 2019 at 23:42, Joe Wang wrote:
>
> +1, looks good to me.
>
> Best regards,
> Joe
>
>
Hi Brent,
The updated webrev looks good to me.
At least, I do not see any issues.
Thanks,
Serguei
On 9/5/19 17:09, Brent Christian wrote:
Hi, David
On 9/5/19 12:52 AM, David Holmes wrote:
Good to see this all come together :)
:)
So to clarify for others any current caller to
25 matches
Mail list logo
