OK well i managed to solve this issue. The key thing i realised is that if you want to control SOAPUI programmically within java you need to rely on numerous lib files which you can get from the lib directory of ready API, but they arent available in their entirety via any maven repository. Oh and By programmically , i mean having the ability to run SOAPUI within specific methods rather than just executing blindly via the POM file. This is important to me because I use BDD framework (cucumber) and so my test execution needs to occur within specific method annotations.
Now the easy solution would be not to use Maven and just kick off my tests directly using testNG or junit, therefore leveraging local the SOAPUI external lib files, however my overall testing approach/architecture is build on Maven, so I needed to use it.
To solve, I essentially copied all the SOAP lib files into the maven local repository and created a dependency on each one within the POM file. Considering there are around 300 lib files, this was only possible using a batch script.
Attached are two files which you guys can use to achieve same result.
create_soapui_repo.bat will look in C:\Program Files\SmartBear\ReadyAPI-2.2.0\lib and put each of these lib files in your local Maven repo. Review the code first then when happy, you can remove the .txt and run it.
POM.xml is a prebuilt POM file with all the dependencies for each jar file.
F.Y.I i built this quickly using string manipulation code so a few of the version references are out. However it will still work due to the folder structure matching in the repo.
Hi workpeter,
Sorry for not replaying sooner, I was out all day yesterday!
Good question, answer and well done sharing it with the community! :smileywink:
The solution that you are describing is very much in line with challenges I have experienced, although I tended to favour Gradle and Groovy (with Grab to resolve dependencies), rather than Maven. Managing the rather large Soapui lib requirements is not only a challenge when running SoapUI as you are, but also when you need to Groovy script in some of the more modern 3rd party client libs e.g. newer Selenium / AWS java API (where they often have newer versions of some of the same libs as SoapUI has resulting in classpath issues, I sometimes found myself have to do dependency gymnastics to get them to work). I remember these 3 being an issue for example:
exclude(module: 'jms')
exclude(module: 'jtidy' )
exclude(module: 'cajo' )
I have been mostly a spectator in the Soapui community for more than a year now, as I have shifted job role more into DevOps from application development, but questions like this make me remember all the improvements / feature requests I wanted to contribute to improve some of these catches. It wouldn't take a lot to make some big improvements. Nice to see you and others are contributing quality posts!
Thanks,
Rupert
While copying the libs, or adding them to the Eclipse project as a library will work, this will probably not be easily deployable on a CI server. I think the correct solution is to make the jars available in your maven repos. I solved this as following:
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-json</artifactId>
<version>2.5.4</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.smartbear.soapui</groupId>
<artifactId>soapui</artifactId>
<version>5.0.0</version>
</dependency>
</dependencies>
You will probably find it useful to create two or three maven build profiles for:
Apache Maven : an introduction to maven profiles
I prefer to keep my automation project completely seperate from the SUT project, but you if you prefer otherwise you could have a seperate profile to build that as well.
