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