NoSuchMethodError: org.hamcrest.Matchers.hasXPath, когда я запускаю тесты в затмении - PullRequest
Новая
       16

NoSuchMethodError: org.hamcrest.Matchers.hasXPath, когда я запускаю тесты в затмении

1 голос
/ 15 ноября 2010

У меня есть модульный тест, использующий библиотеку hamcrest (1.2).Важно, чтобы он был равен 1,2, потому что я хочу включить контекст пространства имен в средство сравнения hasXPath.Это проект maven, и все мои зависимости настроены для корректной работы.(Я уверен, что я использую только junit-dep, а не junit - боль, но я подтвердил, что мое дерево зависимостей верно.) В maven все работает нормально.Однако, когда я запускаю тот же тест в eclipse (3.6), я получаю следующую ошибку: 

java.lang.NoSuchMethodError: org.hamcrest.Matchers.hasXPath(Ljava/lang/String;Ljavax/xml/namespace/NamespaceContext;Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher;
    at com.factorlab.ws.obs.meta.PhenomononGroupsResourceITest.testGetPhenomenonGroupsXml(PhenomononGroupsResourceITest.java:36)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
    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)

Я дважды проверил конфигурацию пути сборки eclipse для проекта, и в ней также есть junit-dep и нетджунит и подголовник 1.2.Кроме того, нет ошибок компиляции, так что это просто время выполнения.Есть ли у Eclipse собственная среда выполнения, которая мешает здесь?Как я могу обойти это?

Код, который вызывает исключение, находится здесь: 

private NamespaceContext namespaceContext = new MetaNamespaceContext();

@Test
public void testGetPhenomenonGroupsXml() throws Exception {
    WebClient webClient = new WebClient();
    webClient.addRequestHeader("Accept", "application/xml");
    XmlPage xmlResult = webClient.getPage(BASE_URL);
    //printDoc(xmlResult.getXmlDocument(), System.out);
    assertThat("count of groups",
            xmlResult.getXmlDocument(),
            hasXPath("count(/phenomenonGroups/om:phenomenonGroup)",
                    namespaceContext, equalTo("4")));
    assertThat("first group",
            xmlResult.getXmlDocument(),
            hasXPath(
                    "/phenomenonGroups/om:phenomenonGroup/om:quickYesNoPhenomenon/id/text()",
                    namespaceContext, equalTo("1")));
}

Я не уверен, что это полезно без тонны контекста - то есть веб-службыкод, полный код класса, зависимые классы, такие как MetaNamespaceContext и т. д. Однако я уверен, что, поскольку все это работает, когда я делаю mvn clean install из командной строки, это должно быть проблемой конфигурации затмения и иметь мало общего сконкретный код выполняется.(За исключением, конечно, что метод hasXPath(String, NamespaceContext, Matcher) доступен только в версии 1.2, и все будет работать нормально, если я просто использую hasXPath(String, Matcher).

Ответы [ 2 ]

2 голосов
/ 23 ноября 2010

Я исправил это, настроив путь сборки и переместив библиотеки hacrest 1.2 в верхнюю часть ордера. Конечно, если я когда-нибудь снова сделаю mvn eclipse:eclipse, мне придется пойти и исправить это снова, так что это не очень хорошее решение, но пока оно работает.

0 голосов
/ 15 декабря 2014

Нажмите Ctrl + Shift + T, чтобы открыть окно поиска типа. введите org.hamcrest.Matchers

Это покажет вам все места на пути к классам проекта, который содержит этот класс. Вы должны увидеть более одной записи в разделе «Соответствующие элементы:», и вы обнаружите, что это разные версии Hamcrest.

...