Hi Igor,
just noticed your change. It is indeed necessary to clarify what is
the best practice here.
Thanks,
Felix
On 2017/6/1 11:32, Igor Ignatyev wrote:
Hi Felix,
I have suggested the exact opposite change[1-3] to fix the same problem.
[1] https://bugs.openjdk.java.net/browse/JDK-8181391
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html
[3]
http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html
<http://cr.openjdk.java.net/%7Eiignatyev//8181391/webrev.00/index.html>
Thanks,
-- Igor
On May 31, 2017, at 8:27 PM, Felix Yang <felix.y...@oracle.com
<mailto:felix.y...@oracle.com>> wrote:
Hi Chris and Daniel,
new webrev with a few of explicit builds than wildcard.
http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/
<http://cr.openjdk.java.net/%7Exiaofeya/8181299/webrev.01/>
Thanks,
Felix
On 2017/5/31 18:20, Chris Hegarty wrote:
On 31 May 2017, at 10:42, Felix Yang <felix.y...@oracle.com
<mailto:felix.y...@oracle.com>> wrote:
Hi there,
please review the patch to various jdk tests to explicitly
compiling test libraries and the lib's dependencies. Though it
could be a jtreg issue (I think so), it is necessary to get the
tests running firstly.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8181299
Webrev:
http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/
<http://cr.openjdk.java.net/%7Exiaofeya/8181299/webrev.00/>
This may be ok to get the tests running again, but explicit build
targets
would be better. The contents, and module dependencies, from classes
in the test library are subject to change, so building all classes may
require more modules than in the @modules tags in the test.
With latest webrev, no new @modules introduced by this change, though
I fixed a missing from original tests.
I prefer to keep "@build jdk.test.lib.process.*" here. Because, with
current test lib package layout, "@build jdk.test.lib.process.*"
equals with
/@build jdk.test.lib.process.OutputAnalyzer
//jdk.test.lib.process.OutputBuffer
//jdk.test.lib.process.ProcessTools
////jdk.test.lib.process.//StreamPumper//
///jdk.test.lib.process.ExitCode/ /"
It is a bit ugly and not productive, when I only use ProcessTools
directly but have to declare a bunch of @builds. That is why I think
this is not a fix but a workaround.
Thanks,
Felix
I agree with Daniel, each test should be run separately in a clean
environment, to verify that it can build the necessary dependencies.
This is actually not the case. I executed repeatedly each test works
well separately. The problem occurs when there are more and more
tests using the same test libs.
As stated in the bugs [1] and [2], if there are multi tests using a
lib, such as ProcessTools, there could be possible collision
occurring on its dependencies.
For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It
looks some dependency classes were treated by jtreg as some-how
shared, and removed unexpectedly.
[1]https://bugs.openjdk.java.net/browse/JDK-8181299
[2]https://bugs.openjdk.java.net/browse/CODETOOLS-7901986.
Thanks,
Felix
This may be a straight forward way to identify explicit build
dependencies
and avoid the wildcards.
-Chris.
