2011-01-21 11 views
11

Estoy tratando de superar mi primer tutorial JMOCK http://www.jmock.org/getting-started.html, y no funcionó bien.JMOCK Dependency Issue

El problema que encontramos es a continuación:

 

java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package 
    at java.lang.ClassLoader.checkCerts(Unknown Source) 
    at java.lang.ClassLoader.preDefineClass(Unknown Source) 
    at java.lang.ClassLoader.defineClassCond(Unknown Source) 
    at java.lang.ClassLoader.defineClass(Unknown Source) 
    at java.security.SecureClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.access$000(Unknown Source) 
    at java.net.URLClassLoader$1.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.net.URLClassLoader.findClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
    at java.lang.ClassLoader.defineClass1(Native Method) 
    at java.lang.ClassLoader.defineClassCond(Unknown Source) 
    at java.lang.ClassLoader.defineClass(Unknown Source) 
    at java.security.SecureClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.access$000(Unknown Source) 
    at java.net.URLClassLoader$1.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.net.URLClassLoader.findClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
    at org.jmock.internal.InvocationExpectationBuilder.createExpectationFrom(InvocationExpectationBuilder.java:86) 
    at org.jmock.internal.InvocationToExpectationTranslator.invoke(InvocationToExpectationTranslator.java:19) 
    at org.jmock.internal.FakeObjectMethods.invoke(FakeObjectMethods.java:38) 
    at org.jmock.lib.JavaReflectionImposteriser$1.invoke(JavaReflectionImposteriser.java:33) 
    at $Proxy8.receive(Unknown Source) 
    at PublisherTest$1.(PublisherTest.java:35) 
    at PublisherTest.oneSubscriberReceivesAMessage(PublisherTest.java:34) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
    at java.lang.reflect.Method.invoke(Unknown Source) 
    at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66) 
    at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:37) 
    at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105) 
    at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86) 
    at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94) 
    at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84) 
    at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49) 
    at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:96) 
    at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:59) 
    at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:52) 
    at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34) 
    at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44) 
    at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:50) 
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) 
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) 
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) 
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) 
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) 
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) 
 

he encontrado una solución en internet. Por favor, ver más abajo:

La solución es asegurarse de que todas las dependencias en JMock JAR ocurren antes de las dependencias de JUnit en todos los plug-in. De esta forma, Hamcrest es cargado desde JMock, no desde JUnit.

Mi comprensión de la solución es: hacer que la clase de prueba use el contenedor de Hamcrest de JMock en lugar del de Junit? ¿Estoy en lo cierto? ¿Qué debo hacer en Eclipse para que esto ocurra?

Gracias,

Sarah

Respuesta

2

usted podría utilizar junit- dep .jar (en lugar de junit.jar) que no incluye los tipos hamcrest. Entonces las referencias de hamcrest en jmock no entrarán en conflicto.

2
<dependency> 
     <groupId>junit</groupId> 
     <artifactId>junit-dep</artifactId> 
     <version>4.8.2</version> 
     <exclusions> 
      <exclusion> 
       <groupId>org.hamcrest</groupId> 
       <artifactId>hamcrest-core</artifactId> 
      </exclusion> 
     </exclusions> 
     <scope>test</scope> 
    </dependency> 
    <dependency> 
     <groupId>org.hamcrest</groupId> 
     <artifactId>hamcrest-all</artifactId> 
     <version>1.3.0RC2</version> 
     <scope>test</scope> 
    </dependency> 
    <dependency> 
     <groupId>org.jmock</groupId> 
     <artifactId>jmock</artifactId> 
     <version>2.6.0-RC2</version> 
     <exclusions> 
      <exclusion> 
       <groupId>org.hamcrest</groupId> 
       <artifactId>hamcrest-core</artifactId> 
      </exclusion> 
      <exclusion> 
       <groupId>org.hamcrest</groupId> 
       <artifactId>hamcrest-library</artifactId> 
      </exclusion> 
      <exclusion> 
       <groupId>org.hamcrest</groupId> 
       <artifactId>hamcrest-unit-test</artifactId> 
      </exclusion> 
     </exclusions> 
     <scope>test</scope> 
    </dependency> 
    <!-- next libs are optional --> 
    <dependency> 
     <groupId>org.jmock</groupId> 
     <artifactId>jmock-junit3</artifactId> 
     <version>2.6.0-RC2</version> 
     <exclusions> 
      <exclusion> 
       <groupId>junit</groupId> 
       <artifactId>junit</artifactId> 
      </exclusion> 
     </exclusions> 
     <scope>test</scope> 
    </dependency> 
    <dependency> 
     <groupId>org.jmock</groupId> 
     <artifactId>jmock-legacy</artifactId> 
     <version>2.6.0-RC2</version> 
     <scope>test</scope> 
    </dependency> 
+0

Intenté editar esto, pero solo necesitaba cambiar algunas letras, así que SO no me lo permitió. Asegúrese de cambiar la versión de Hamcrest de 1.3.0-RC2 a 1.3, porque esa es la última y mejor versión disponible. – mooreds

8

Las bibliotecas de la orden en los Eclipse construir de configuración son:

hamcrest-core-1.2.jar hamcrest-library-1.2.jar JMock-2.5.1.jar JRE [JavaSE-1,6 ] JUnit_4.8.1.jar (parte de la distribución del eclipse) hamcrest.core_1.1.0 (incluido con JUnit 4.8.1)

la solución es simple - asegurarse de que es hamcrest.jar antes de la biblioteca JUnit incluido por Eclipse en el classpath.

Creo que si nos fijamos en la pestaña "Ordenar y exportar" en la propiedad de la ruta de compilación java (Configurar ruta de compilación), encontrará que el jarrón JUnit está por encima de hamcrest.jar. Puedes mover el hamcrest arriba del jarrón JUnit aquí y el problema desaparecerá.

2

Esto me sucedió debido a las dependencias de JUnit duplicadas en el proyecto. Una agregada por eclipse y otra desde dependencias de Maven (m2eclipse/m2e agrega esto a classpath también).

Así eliminar el añadido por Eclipse para proyectar yendo a Proyecto> Propiedades> Vía de construcción

Véase más abajo. enter image description here

0

Me encontré con el mismo problema al intentar ejecutar las pruebas en un proyecto que no era Eclipse y que acababa de importar. Después de mirar las otras respuestas aquí, noté que el pom.xml especificó JUnit .

Así que simplemente cambié "JUNIT_CONTAINER/4" a "JUNIT_CONTAINER/3" en .classpath ... y todas las pruebas tuvieron éxito.