Проблема зависимости JMOCK - PullRequest
11 голосов
/ 21 января 2011

Я пытаюсь пройти мой самый первый урок по JMOCK http://www.jmock.org/getting-started.html,, и он не удался.

Проблема, с которой я столкнулся, ниже:


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)

Я нашел решение в интернете. Пожалуйста, смотрите ниже:

Решение состоит в том, чтобы обеспечить наличие любых зависимостей от JMock JAR до зависимости от JUnit в каждом плагине. Таким образом, Хэмкрест загружается из JMock, а не из JUnit.

Мое понимание решения таково: заставить тестовый класс использовать банку с подколенным сухожилием от JMock вместо джунта? Я прав? Что я должен сделать в Eclipse, чтобы это произошло?

Спасибо

Сара

Ответы [ 5 ]

8 голосов
/ 16 марта 2011

Порядок библиотек в конфигурации сборки Eclipse:

hamcrest-core-1.2.jar hamcrest-library-1.2.jar jmock-2.5.1.jar JRE [JavaSE-1.6] JUnit_4.8.1.jar (часть дистрибутива eclipse) hamcrest.core_1.1.0 (в комплекте с JUnit 4.8.1)

Решение простое - убедитесь, что hamcrest.jar находится перед библиотекой JUnit, включенной Eclipse в classpath.

Я полагаю, что если вы посмотрите на вкладку «Порядок и экспорт» в свойстве пути сборки Java (Configure Build Path), вы обнаружите, что JUnit jar находится выше hamcrest.jar.Вы можете переместить подголовник выше банки JUnit здесь, и проблема исчезнет.

2 голосов
/ 07 июня 2012

Это случилось со мной из-за дублированных зависимостей JUnit от проекта. Один добавлен eclipse, а другой из зависимостей Maven (m2eclipse / m2e также добавляет этот к classpath).

Так что удалите тот, который был добавлен eclipse в проект, перейдя в Project> Properties> Build Path

Смотри ниже. enter image description here

2 голосов
/ 31 января 2011
    <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>
2 голосов
/ 22 января 2011

Вы можете использовать junit- dep .jar (вместо junit.jar), который не включает типы хамкрестов.Тогда ссылки на хамкрест в jmock не будут конфликтовать.

0 голосов
/ 21 июня 2012

Я только что столкнулся с той же проблемой, пытаясь запустить тесты в не-Eclipse-проекте, который я только что импортировал.Посмотрев здесь другие ответы, я заметил, что в pom.xml указан JUnit 3 .

Так что я просто изменил "JUNIT_CONTAINER / 4" на "JUNIT_CONTAINER / 3" в .classpath... и все тесты пройдены успешно.

...