Forum Discussion

TooDizzy's avatar
TooDizzy
Occasional Contributor
8 years ago
Solved

Composite build will not execute on build server, but runs locally

Hi Guys,

 

I'm having a serious problem executing my SOAP UI Pro build. I'm running Ready API 1.8.5 and my project is a composite project.

When I run it locally (the maven build) everything runs fine and the test starts as expected.

Running the same build on our build server results in the below error. It can't, for some weird reason, suddenly not find the project.xml. It's a composite project so I have only specified the folder of the project - and it runs locally.

 

The build server has a valid license installed.

 

For the maven build I use the latest available plug-in:

<groupId>com.smartbear</groupId>
<artifactId>ready-api-maven-plugin</artifactId>
<version>1.8.1</version>

Here the exception:

t com.eviware.soapui.impl.wsdl.WsdlProjectPro.<init>(WsdlProjectPro.java:180)
	at com.eviware.soapui.impl.wsdl.WsdlProjectProFactory.createNew(WsdlProjectProFactory.java:92)
	at com.eviware.soapui.impl.wsdl.WsdlProjectProFactory.createNew(WsdlProjectProFactory.java:1)
	at com.smartbear.ready.cmd.runner.AbstractSoapUIRunner.getWsdlProject(AbstractSoapUIRunner.java:378)
	at com.smartbear.ready.cmd.runner.SoapUITestCaseRunner.runRunner(SoapUITestCaseRunner.java:356)
	at com.smartbear.ready.cmd.runner.pro.SoapUIProTestCaseRunner.runRunner(SoapUIProTestCaseRunner.java:98)
	at com.smartbear.ready.cmd.runner.AbstractSoapUIRunner.run(AbstractSoapUIRunner.java:257)
	at com.eviware.soapui.maven2.TestMojo.execute(TestMojo.java:152)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
	at org.jvnet.hudson.maven3.launcher.Maven32Launcher.main(Maven32Launcher.java:132)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
	at jenkins.maven3.agent.Maven32Main.launch(Maven32Main.java:186)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:136)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:71)
	at hudson.remoting.UserRequest.perform(UserRequest.java:121)
	at hudson.remoting.UserRequest.perform(UserRequest.java:49)
	at hudson.remoting.Request$2.run(Request.java:325)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.xmlbeans.XmlException: error: Unexpected element: CDATA
	at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3486)
	at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1276)
	at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1263)
	at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
	at com.eviware.soapui.config.SoapuiProjectDocumentConfig$Factory.parse(Unknown Source)
	at com.eviware.soapui.impl.wsdl.WsdlProjectPro.b(WsdlProjectPro.java:541)
	at com.eviware.soapui.impl.wsdl.WsdlProjectPro.loadProject(WsdlProjectPro.java:354)
	... 42 more
Caused by: org.xml.sax.SAXParseException; systemId: file:; lineNumber: 1; columnNumber: 1; Unexpected element: CDATA
	at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportFatalError(Piccolo.java:1038)
	at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:723)
	at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3454)
	... 48 more

 

 

Any ideas to resolve this are most welcome.

Thanks!

 

/Tue

  • TooDizzy's avatar
    TooDizzy
    8 years ago

    found the problem.

     

    I had a . in the build name.

    On the jenkins server this results on a folder structure with the build name as the checkout path. Here we then have "." in the path. Perfectly normal and legit on linux, but it was too much for the Ready API plugin.

     

    Sounds like a path related in the plugin.

     

    /Tue

2 Replies

  • testhrishi's avatar
    testhrishi
    Frequent Contributor

    If the same project runs from within readyAPI, the only reason I can think of is the project path. make sure that the project path you have specified to the command is appropriate (foldername etc case sensitive)

    • TooDizzy's avatar
      TooDizzy
      Occasional Contributor

      found the problem.

       

      I had a . in the build name.

      On the jenkins server this results on a folder structure with the build name as the checkout path. Here we then have "." in the path. Perfectly normal and legit on linux, but it was too much for the Ready API plugin.

       

      Sounds like a path related in the plugin.

       

      /Tue