Forum Discussion
redfish4ktc2
12 years agoSuper Contributor
Hi
I agree with you, I will love this too. Unfortunately, there is work to do before this happens.
1st of all, even if soapui artifacts were published on central, there would be an issue with their dependencies.
Before soapui 4.5.2, soapui was built using maven 1. So artifacts in the soapui maven 2 repository where pushed manually without declaring any dependencies. In the maven plugin pom, dependencies were directly declared and this lead to missing dependencies at runtime in almost all versions.
Additionaly, the soapui maven plugin pom declared dependencies with groupId and artifactId which are not the same that in central. This is maybe something that comes from the old maven 1 build. These artifacts with different maven coordinates are only available on the soapui repository.
Starting from soapui 4.5.2, the build now uses maven 2/3 so dependency management is now provided directly from the soapui pom.
But no artifact coordinates migration has been performed.
I've started working on this (see https://github.com/redfish4ktc/soapui/t ... es-groupId)
A lot of dependencies could be retrieved from central but I am pestimistic about suceeding quickly with all of them
- some are not on central, for instance, soapui can run embeded web browser; this feature is provided by a proprietary package (teamdev)
- some seem to have been patched by smartbear (xmlbean-fixed) and I don't know what are the fixes and if the fixes are available on public newer versions
- some versions need to be upgraded because the current used version is not available on central (rsyntaxtextarea)
All these need to be discuss with SmartBear
About the artifacts upload, we are still waiting for the 4.5.2 artifacts whereas this version has been available for almost 2 months (soapui 4.5.2 release date is 22-may-2013). I don't know if SmartBear has planned to change the way artifacts are published (see viewtopic.php?f=2&t=19103)
There is no also a new issue. Starting from 4.5.2, the soapui repository is declared in the pom. As you mention, this is a bad practice.
I will discuss with SmartBear about this to make them remove this.
To finish, the soapui maven repository is unstable, it does not always response when the build request artifact downloads (see viewtopic.php?f=5&t=18565 or viewtopic.php?f=13&t=19404).
Currently, the only way to have reliable builds is to set up a repository manager and proxy the soapui maven repository.
Tell me if it is clearer now.
I agree with you, I will love this too. Unfortunately, there is work to do before this happens.
1st of all, even if soapui artifacts were published on central, there would be an issue with their dependencies.
Before soapui 4.5.2, soapui was built using maven 1. So artifacts in the soapui maven 2 repository where pushed manually without declaring any dependencies. In the maven plugin pom, dependencies were directly declared and this lead to missing dependencies at runtime in almost all versions.
Additionaly, the soapui maven plugin pom declared dependencies with groupId and artifactId which are not the same that in central. This is maybe something that comes from the old maven 1 build. These artifacts with different maven coordinates are only available on the soapui repository.
Starting from soapui 4.5.2, the build now uses maven 2/3 so dependency management is now provided directly from the soapui pom.
But no artifact coordinates migration has been performed.
I've started working on this (see https://github.com/redfish4ktc/soapui/t ... es-groupId)
A lot of dependencies could be retrieved from central but I am pestimistic about suceeding quickly with all of them
- some are not on central, for instance, soapui can run embeded web browser; this feature is provided by a proprietary package (teamdev)
- some seem to have been patched by smartbear (xmlbean-fixed) and I don't know what are the fixes and if the fixes are available on public newer versions
- some versions need to be upgraded because the current used version is not available on central (rsyntaxtextarea)
All these need to be discuss with SmartBear
About the artifacts upload, we are still waiting for the 4.5.2 artifacts whereas this version has been available for almost 2 months (soapui 4.5.2 release date is 22-may-2013). I don't know if SmartBear has planned to change the way artifacts are published (see viewtopic.php?f=2&t=19103)
There is no also a new issue. Starting from 4.5.2, the soapui repository is declared in the pom. As you mention, this is a bad practice.
I will discuss with SmartBear about this to make them remove this.
To finish, the soapui maven repository is unstable, it does not always response when the build request artifact downloads (see viewtopic.php?f=5&t=18565 or viewtopic.php?f=13&t=19404).
Currently, the only way to have reliable builds is to set up a repository manager and proxy the soapui maven repository.
Tell me if it is clearer now.
Related Content
- 14 years ago
Recent Discussions
- 5 hours ago
- 4 days ago
xml to soap
Solved4 days ago- 5 days ago