OK. Current changes for exclude lists were integrated and now we have
3-level exclude list:
exlude.common - tests, that failed over all platforms
exclude.<platform> - tests, that failed over specific platform only
exclude.<platform>.interm - tests that failed time to time over specific
platform only.
Any file in this chain may be skipped. Final exclude lists are generated at
the build time and stored to the ${hy.hdk}/build directory. Thanks to Alexei
Zakharov for this changes.
But I have one more question to discuss: should we use the tests from
'intermittently failed' exclude list for preintegration testing? If we use
it we may miss some regression when intermittently failed test will failed
constantly however if we does not use it we need to run test twice
sometimes.
What is correct behavior?
thanks, Vladimir
On 1/28/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
Yeah, +1 for using common exclude lists. It makes it easier when
Harmony gets ported to other operating systems. And I don't see the
benefit of having empty lists in that case; and if nothing's failing,
you don't need an empty list either :-)
Alex.
On 28/01/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> +1 from me for using common exclude lists and removing empty lists.
>
> SY, Alexey
>
> 2007/1/16, Alexey Varlamov <[EMAIL PROTECTED]>:
> > Folks,
> >
> > I've some concerns with recent updates for x-list support: can we use
> > a common macros instead of copy-pasting 4 new targets into build.xml
> > for each module?
> > Or, if we can neglect creating a compiled x-file
> > (${hy.hdk}/build/<module>.exclude), just use "if" attribute of
> > <excludesfile>, like this:
> >
> > <available property="x.list.exist"
> > file="exclude.${hy.platform}.${hy.test.vm.name}"/>
> > ...
> > <batchtest>
> > <fileset dir="${src.test.java}">
> > <include name="**/*Test.java"/>
> > <excludesfile name="exclude.common"/>
> > <excludesfile name="${exclude.file} if="
x.list.exist" />
> > </fileset>
> > </batchtest>
> >
> > Also, I suggest to delete empty x-list remained after introducing
common lists.
> >
> > Another issue is with "hy.test.vm.name", it was a surprise for me that
> > it is not autodetected yet. Most obvious way to get it is to read
> > "java.vm.name" property, this only requires running trivial test.
> >
> > --
> > Alexey
> >
>
