<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Chris and Daniel,</p>
<p> new webrev with a few of explicit builds than wildcard.</p>
<p><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/">http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/</a><br>
</p>
Thanks,<br>
Felix<br>
<div class="moz-cite-prefix">On 2017/5/31 18:20, Chris Hegarty
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AAF50FC4-ACA9-4FB9-8252-C544F2684FE0@oracle.com">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On 31 May 2017, at 10:42, Felix Yang <a class="moz-txt-link-rfc2396E" href="mailto:felix.yang@oracle.com"><felix.yang@oracle.com></a> 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:
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8181299">https://bugs.openjdk.java.net/browse/JDK-8181299</a>
Webrev:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/">http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/</a>
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
With latest webrev, no new @modules introduced by this change,
though I fixed a missing from original tests.<br>
<br>
I prefer to keep "<span class="changed"><font color="#3333ff">@build
jdk.test.lib.process</font></span>.*" here. Because, with
current test lib package layout, "<span class="changed"><font
color="#3333ff">@build jdk.test.lib.process</font></span>.*"
equals with <span class="changed"><br>
</span><font color="#3333ff"><i><span class="changed">@build
jdk.test.lib.process.OutputAnalyzer<br>
</span></i><i><span class="changed"><span
class="changed">jdk.test.lib.process.</span>OutputBuffer<br>
</span></i><i><span class="changed"><span class="changed">
</span><span class="changed"><span class="changed">jdk.test.lib.process.</span></span>ProcessTools<br>
</span></i></font><span class="changed"><font color="#3333ff"><i><span
class="changed"> </span></i><i><span
class="changed"><span class="changed">jdk.test.lib.process.</span></span></i><i>StreamPumper</i><i><br>
</i></font></span><span class="changed"><font color="#3333ff"><i><span
class="changed"><font color="#3333ff"><i><span
class="changed"><span class="changed">
jdk.test.lib.process.ExitCode</span></span></i></font></span>
</i></font>"</span><br>
<span class="changed"><span class="changed"><br>
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.<br>
<br>
Thanks,<br>
Felix<br>
</span></span>
<blockquote type="cite"
cite="mid:AAF50FC4-ACA9-4FB9-8252-C544F2684FE0@oracle.com">
<pre wrap="">
I agree with Daniel, each test should be run separately in a clean
environment, to verify that it can build the necessary dependencies.</pre>
</blockquote>
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.<br>
<br>
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.<br>
For ProcessTools, StreamPumper (ONLY) will be disappear sometimes.
It looks some dependency classes were treated by jtreg as some-how
shared, and removed unexpectedly.<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8181299">https://bugs.openjdk.java.net/browse/JDK-8181299</a><br>
[2] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/CODETOOLS-7901986">https://bugs.openjdk.java.net/browse/CODETOOLS-7901986</a>.<br>
<br>
Thanks,<br>
Felix<br>
<blockquote type="cite"
cite="mid:AAF50FC4-ACA9-4FB9-8252-C544F2684FE0@oracle.com">
<pre wrap="">
This may be a straight forward way to identify explicit build dependencies
and avoid the wildcards.</pre>
</blockquote>
<blockquote type="cite"
cite="mid:AAF50FC4-ACA9-4FB9-8252-C544F2684FE0@oracle.com">
<pre wrap="">
-Chris.
</pre>
</blockquote>
<br>
</body>
</html>