On 13/07/15 13:53, Claude Warren wrote:
It is possible (and probable) that the contract code scanner is loading
them. At one point I thought I was loading classes but not initializing
them. I will look into this.
Not urgent as my fix seems to have fixed it [famous last words]. (and
now maven versions and excessive javadoc warnings on unknown tags that
aren't even used!)
The assembler test code was using static initializers to set a "I've
loaded" flag.
Andy
Claude
On Mon, Jul 13, 2015 at 1:27 PM, Andy Seaborne <a...@apache.org> wrote:
Claude,
This is "for information" - I think I've solved the problem.
A couple of days ago I corrected the surefire test setup to explicitly
name TestPackage (was com.hp.hpl. ...).
<includes>
<include>org/apache/jena/test/TestPackage.java</include>
<include>**/*_CS.java</include>
</includes>
and now we have:
https://builds.apache.org/job/Jena_Development_Test/1992/testReport/
The two tests failing have inner test classes in TestAssemblerHelp and
TestAssemblerGroup to be loaded so that the tests which try to detect that
before they aren't loaded and after some assembler action are loaded then
fail.
Is that possible? Could the contract code be causing an early load of the
inner classes to scan them?
Solution: there is a static method called on a class loaded buy an
assembler every time loadClass is used. I got that to set "I was loaded"
flag instead.
Andy
