I can quite see right now how prop order is causing the problem... The surefire test reports lead in another direction...for example, not sure if was *the* problem but apparently *a* problem is something that surfaced in jmock 1.2.0 .....described somewhat here:
http://markmail.org/message/wd6oqfcwtoo5t4h6#query:jmock%20java.lang.IllegalAccessError%3A%20superinterface+page:1+mid:wd6oqfcwtoo5t4h6+state:results I changed the visibility of the ContentCreator interface to be public and the tests succeed now The build now fails much later on (as a result of my 'fix'?), in one of the executions of LaunchPad's dependency expansion phase: [INFO] [dependency:unpack-dependencies {execution: inline-framework-bundles}] [INFO] Expanding: /home/ccjon/.m2/repository/org/apache/felix/org.apache.felix.framework/1.0.4/org.apache.felix.framework-1.0.4.jar into /home/ccjon/sling/launchpad/app/target/classes org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. On Tue, Aug 26, 2008 at 12:52 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Tue, Aug 26, 2008 at 9:40 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > >> ...The tests do simple string comparision, which >> do not take into account that the reported properties can come in any >> order.... > > Other tests like [1] actually evaluate the returned json code to > verify test values. I guess the > org.apache.sling.jcr.contentloader.internal.JsonReaderTest should be > modified to use a similar testing method and avoid the "out of order > properties" problem. > > -Bertrand > > [1] > http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/JsonRenderingTest.java > -- Jon Gorrono email{>+++++++++[>+++++++++++>++++++++++++>+++++++>+++++<<<<-]>+++++++.>++++.<---.>-.+++..---.-.+.>+.<++++++.<----.+.---.>+.<++++++++.>---.>>+.<<<----.-.>++.} http{ats.ucdavis.edu}
