jena-core tests and contract tests

2015-07-13 Thread Andy Seaborne

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
includeorg/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

2015-07-13 Thread Claude Warren
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 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
 includeorg/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


Re: jena-core tests and contract tests

2015-07-13 Thread Andy Seaborne

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
 includeorg/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