Forum Discussion

kdaham's avatar
kdaham
Occasional Contributor
11 years ago

soapui junit

I get the following on all tests that have a match assertion, when running a testsuite in a project with the help of SoapUITestCaseRunner (where is the 4.6.x version of it anyway?)

[Match content of [hsaID]] Could not initialize class com.eviware.soapui.impl.rest.support.MediaTypeHandlerRegistry

Which makes the test fail ofc, I cant see that class in any of the jar-files I usually depend on, any extra dependency that is required? Is it documented anywhere?

7 Replies

  • kdaham's avatar
    kdaham
    Occasional Contributor
    Ok I found the 4.6.3 in com.smartbear, but the .pom files in some dependencies needs some cleanup.

    * What went wrong:
    Could not resolve all dependencies for configuration ':capacity:testCompile'.
    > Could not resolve jtidy:jtidy:r872-jdk15.
    Required by:
    se.sll.service.catalogue:capacity:1.0-SNAPSHOT > com.smartbear.soapui:soapui:4.6.3
    > Could not resolve jtidy:jtidy:r872-jdk15.
    > inconsistent module metadata found. Descriptor: org.gradle.api.internal.externalresource.DefaultLocallyAvailableExternalResource@3a126636 Errors: bad version: expected='r872-jdk15' found='r872'
    > Could not resolve jtidy:jtidy:r872-jdk15.
    > inconsistent module metadata found. Descriptor: Http GET Resource: http://www.soapui.org/repository/maven2 ... -jdk15.pom Errors: bad version: expected='r872-jdk15' found='r872'
    > Could not resolve gnu.cajo:cajo:1.142.
    Required by:
    se.sll.service.catalogue:capacity:1.0-SNAPSHOT > com.smartbear.soapui:soapui:4.6.3
    > Could not resolve gnu.cajo:cajo:1.142.
    > inconsistent module metadata found. Descriptor: org.gradle.api.internal.externalresource.DefaultLocallyAvailableExternalResource@6fac5e74 Errors: bad group: expected='gnu.cajo' found='cajo'
    > Could not resolve gnu.cajo:cajo:1.142.
    > inconsistent module metadata found. Descriptor: Http GET Resource: http://www.soapui.org/repository/maven2 ... -1.142.pom Errors: bad group: expected='gnu.cajo' found='cajo'
  • kdaham's avatar
    kdaham
    Occasional Contributor
    After manually adding rsyntaxtextarea, jtidy-r872-jdk15 and cajo-1.142 to my local repository 4.6.3 managed to run the project with all test suites passing.
    But it would help tremendously if the above 3 dependencies where fixed.
  • redfish4ktc2's avatar
    redfish4ktc2
    Super Contributor
    Hi, thanks for this feedback
    it seems you use gradle and that gradle performs more checks on the pom than maven does :-) Is that right?

    for cajo, the directory layout is ok in the repo, but the group id is wrong in the pom. I've also seen this problem when using soapui pro with the jasper reports lib (see https://github.com/redfish4ktc/maven-so ... /issues/67)
    for jtidy, jdk15 is a classifier, so the directory layout should be http://www.soapui.org/repository/maven2 ... tidy/r872/ and the jar with the classifier should be stored here.

    I've wrote a post in a soapui forum about why soapui does not use regular maven artifact coordinates and what should be done, see viewtopic.php?f=5&t=20368&p=45977#p45977
  • kdaham's avatar
    kdaham
    Occasional Contributor
    Yes I do run gradle, and I already installed the jar files in my local repo so I got it to work, but wrong pom-files is well just wrong.
    And if I'm not mistaken this will be a nuisance for maven3 as well which is more strict than m1 and m2.
  • redfish4ktc2's avatar
    redfish4ktc2
    Super Contributor
    kdaham thanks for the information
    maybe my previous post was not clear. I totally agree with you, the poms are wrong and this should be fixed.

    For your maven 3 remark, I regularly use maven 3.0.x and 3.1.x; it does not complain about the problem when using the default configuration. Do you have more information about this?
  • I get the following on all tests that have a match assertion, when running a testsuite in a project with the help of SoapUITestCaseRunner......................
    • PJat's avatar
      PJat
      Contributor

      Better late than never, these pom files have been fixed now. Thanks for reporting.