Forum Discussion
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:
- Cloning the SOAPUI project from GitHub locally.
- https://github.com/SmartBear/soapui
- mvn clean install to add your local maven repo.
- To make available on Jenkins or your CI, add a job build to your teams CI maven repo.
- Add the following dependencies to the test projects POM.XML
<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:
- java for cucumber-jvm,
- groovy for to develop groovy scripts inside Eclipse
- automation to test against the actual project.
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.
Related Content
- 11 years ago
- 2 years ago