<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 12/11/13 07:54 PM, Alan Bateman
      wrote:<br>
    </div>
    <blockquote cite="mid:52A8C2E5.7010505@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 11/12/2013 19:26, Balchandra Vaidya wrote:
      <blockquote cite="mid:52A8BC76.60409@oracle.com" type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <br>
        :<br>
        <br>
        <blockquote cite="mid:52A8A72C.7050300@oracle.com" type="cite">Alternatively,


          that segment of the script could be a candidate for a target
          in <br>
          one or more test/Makefile files. <br>
        </blockquote>
        <br>
        This is good idea, but my experience with the 'make' is that if
        one target critically fail, all<br>
        subsequent targets will not run. I thought it is a restriction
        of 'make'.<br>
        <br>
      </blockquote>
      I think Jon is suggesting that the subset that you run be added to
      TEST.groups (which will automatically turn it a make targe as way
      of the jdk_% rule ). On the surface this is a good idea but when I
      look at the subset of the tests that you are running:<br>
      <br>
      :jdk_core<br>
      :jdk_svc<br>
      :jdk_beans<br>
      :jdk_imageio<br>
      :jdk_sound<br>
      :jdk_sctp<br>
      javax/accessibility <br>
      com/sun/java/swing <br>
      javax/print<br>
      sun/pisces <br>
      com/sun/awt <br>
      <br>
      then it's a bit ad hoc. I wouldn't object to adding a special
      group for this but it really amounts to all jdk tests except for:<br>
      <br>
      java/awt<br>
      javax/swing<br>
      sun/awt<br>
      sun/java2d<br>
      com/apple/eawt<br>
      <br>
    </blockquote>
    <br>
    I think it make sense to have an actively managed :jdk_stable group.
    I<br>
    know that all tests in e.g. javax/swing are not unstable, but it is
    a matter<br>
    of time (and testing on various OS) to figure out the unstable tests<br>
    that are causing the pain.<br>
    <br>
    Thanks<br>
    Balchandra<br>
    <br>
    <blockquote cite="mid:52A8C2E5.7010505@oracle.com" type="cite"> If
      these tests aren't in your runs because of stability issues then
      we should make sure that there are bugs submitted and that they
      get some focus. In the interim then unstable tests can be
      @ignore-d or added to the exclude list. I initially thought that
      part of the issue was the othervm vs. agentvm discussion but I see
      in TEST.ROOT that othervm.dirs lists these directories already.<br>
      <br>
      -Alan<br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>