Forum Discussion

SiKing's avatar
SiKing
Community Hero
13 years ago

SoapUI releases in Maven

What is the typical delay between a new SoapUI release and same being available from the Maven repo? 4.5.2 has been out for a while, but still nothing at http://www.soapui.org/repository/maven2/

18 Replies

  • Thanks for bringing this to our attention. I agree that we should upgrade the Groovy lib ASAP – I'll add this to the backlog for prioritization right away.

    Any other libs you want us to look at while we're at it?

    Best regards,
    Manne Fagerlind
    SmartBear Sweden
  • SiKing's avatar
    SiKing
    Community Hero
    The Groovy lib is definitely the most important. I have not run into problems with any others - I think some of the org.apache are slightly dated, but nothing critical. I would say start looking at the ones that have the greatest impact on your code?
    Also, and I have mentioned this before to some of your staff, consider croudtesting some of this. I have been using groovy-2.1.1 since SoapUI version 4.5.0, and so far no problems!
  • redfish4ktc2's avatar
    redfish4ktc2
    Super Contributor
    Hi, the current main concern about dependencies is that soapui does not use regular maven coordinates (see viewtopic.php?f=5&t=20368). This prevents users to override versions of the maven plugin dependencies and make dependency management a mess when including soapui in a java project (whatever build tool with dependency management you use).

    Let's take the groovy example with the maven plugin.
    Current groovy version is 1.8.0 and I want to use version 2.1.1
    I could override the version like this

    <plugin>
    <groupId>eviware</groupId>
    <artifactId>maven-soapui-pro-plugin</artifactId>
    <version>4.5.1</version>
    <dependencies>
    <dependency>
    <groupId>groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>2.1.1</version>
    </dependency>
    </dependencies>
    </plugin>


    but there is no version greater than 1.8.0 in the soapui repository nor in maven central

    I could add the groovy dependency with regular maven coordinates (groupId org.codehaus.groovy) but in this case, I would have to exclude the original groovy dependency (to be sure the plugin uses mine) BUT this is not supported by Maven!!!


    SiKing you can give a try to https://github.com/redfish4ktc/maven-so ... ion-plugin. This plugin uses regular groovy maven coordinates so you should be able to use the groovy version you want by overriding the version as in my example.
    This was not a feature I directly planned to add in my plugin but if it can help, this is a good thing

    As I previously wrote in this post, I've planned to provide a pull request to the soapui dev team to help in moving forward and use regular maven coordinates when possible (home in a few weeks)
  • SiKing's avatar
    SiKing
    Community Hero
    I guess if you ("I" in this case) complain enough ...
  • Hi!

    We're working on upgrading Groovy, but unfortunately there are some known issues in terms of backwards compatibility that we need to have a closer look at.
    In the meanwhile, you could try downloading the latest groovy-all jar from here: http://search.maven.org/#artifactdetail ... .1.7%7Cjar and replace the current one in the /lib folder of your SoapUI Pro installation folder.

    --
    Regards

    Erik
    SmartBear Sweden
  • SiKing's avatar
    SiKing
    Community Hero
    Is this for testing purposes, or are you suggesting this as a workaround? I have been running for a while with Groovy 2.1.1 (so I have a workaround), but do not mind upgrading that further (to help out with testing).
  • SiKing wrote:
    Is this for testing purposes, or are you suggesting this as a workaround? I have been running for a while with Groovy 2.1.1 (so I have a workaround), but do not mind upgrading that further (to help out with testing).


    A little bit of both. It's good to hear that people are running this without problems (and if you do encounter any issues, please let us know). We want to upgrade the groovy version in the future, but we also want to make sure to investigate the risk of breaking users' existing scripts before.

    Regards,
    Arian
    SmartBear Sweden