You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2015/07/13 14:27:37 UTC
jena-core tests and contract tests
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
Re: jena-core tests and contract tests
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@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
>>
>
>
>
Re: jena-core tests and contract tests
Posted by Claude Warren <cl...@xenei.com>.
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.
Claude
On Mon, Jul 13, 2015 at 1:27 PM, Andy Seaborne <an...@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
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren