xebialabs-community / gradle-xld-plugin Goto Github PK

As implemented DarTask doAfterEvaluate() can do real work during the configuration stage. This is a problem in that a build that does not involve running the DarTask will still do the work of processing the manifest file. The performance hit in a large project with many subprojects with the gradle-xld-plugin can be significant.

Also the DarTask does not properly declare it's inputs and outputs so UP-TO-DATE checking is broken. You can see this in that it takes three "build" runs before the DarTask stabilizes as UP-TO-DATE.

The way to fix this is to move the processManifest() processing into a separate task with it's own inputs and outputs and declare the DarTask as dependsOn() on the new task. Then all the work will be done execution time rather than configuration time and UP-TO-DATE checking will work correctly.

The plugin takes into account the commented part of deployit-manifest.xml and try to execute the commented code !!

<?xml version="1.0" encoding="UTF-8"?>
<udm.DeploymentPackage version="${noSnapshot(project.warFromNexusVersion)}" application="${project.xl_deploy_app_id}">
    <deployables>
        <tomcat.War name="${project.xl_deploy_app_id}" file="${artifact(project.warFromNexus)}" >
            <tags>
                <value>${project.xl_deploy_app_id}</value>
            </tags>
            <contextRoot>${project.xl_deploy_app_id}</contextRoot>
        </tomcat.War>
        <hug.ClasspathFile name="${project.xl_deploy_app_id}-config-files" file="${artifact(project.zipConfig)}">
            <tags>${project.xl_deploy_app_id}</tags>
        </hug.ClasspathFile>
        <!--<hug.WorkdirFolder name="${project.xl_deploy_app_id}-application-files" file="${artifact(project.applicationFiles)}">
            <tags>
                <value>${project.xl_deploy_app_id}</value>
            </tags>
            <targetFolder>bin/mongodb</targetFolder>
        </hug.WorkdirFolder>-->
    </deployables>
</udm.DeploymentPackage>

The commented part of this file is still evaluated and executed and crashing with an error.

Hi.

We are using the maven plugin to create dar packages and to import them into XL Deploy 4.5.3. This plugin creates a dar package with all our war files in a flat-structured way.

I tried this plugin and it looks very promising, but I'm getting an error when the plugin tries to import the dar package:

com.xebialabs.deployit.exception.RuntimeIOException: The file artifacts\webshop-animal\build\libs/webshop-animal.war could not be found in the package.

All the war files are like you can see, wrapped into artifacts<module_name>\build\libs/<module_name>.war. The path is correct and the war file exists in the dar package. I guess it could be the forward slash at the end? Any ideas?

PS, We use a multi-project gradle setup, and the manifest file looks like this (truncated):

<?xml version="1.0" encoding="UTF-8"?>
<udm.DeploymentPackage version="${project.property('xldeploy-version')}" application="webshop-deployit-bundle">
    <deployables>
        <was.War name="webshop-animal" file="${artifact(project.findProject('webshop-animal').war)}">
            <excludeFileNamesRegex>.+\\.(jar)</excludeFileNamesRegex>
            <scanPlaceholders>true</scanPlaceholders>
            <contextRoot>/webshop-animal</contextRoot>
            <virtualHostName>intranet_host</virtualHostName>
            <classloaderMode>PARENT_LAST</classloaderMode>
            <warClassloaderMode>PARENT_LAST</warClassloaderMode>
        </was.War>
    </deployables>
</udm.DeploymentPackage>

Hi,

I get the following error when using the plug-in with Gradle 7.0:

• What went wrong:
  An exception occurred applying plugin request [id: 'com.xebialabs.xl-deploy', version: '0.6.2']

Failed to apply plugin 'com.xebialabs.xl-deploy'.
No such property: UPLOAD_GROUP for class: org.gradle.api.plugins.BasePlugin

Any ideas?

I am getting
'No such property: deletePreviouslyDeployedDar for class: com.xebialabs.gradle.xldeploy.XlDeployPluginExtension_Decorated'

when running a 'clean dar deploy', with this config

xldeploy {
    xldUrl = xldeployUrl
    xldUsername = xldeployUsername
    xldPassword = xldeployPassword
    manifest = file('setupscripts\\xl_deploy\\deployit-manifest.xml')
    deletePreviouslyDeployedDar = true
}

Hello,

I'm trying to implement following workflow

1. Build the atrifact
2. Generate deployit-manifest.xml
3. Build DAR package
4. Deploy DAR into Sonatype Nexus
5. Deploy DAR file into XL deploy

Because I have dozens of artifacts which have dozens of parameters so I can't hardcode them into static manifest files.

Looks like this way impossible with current version of gradle-xld-plugin
The plugin is trying parse Manifest file during configuration phase before build

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':XXXXX-data-db'.
> DAR manifest file does not exist: [/home/XXXXX/git/tibco-esb/DTL/XXXXX/XXXXX-data-db/build/deployit-manifest.xml]
   > /home/XXXXX/git/tibco-esb/DTL/XXXXX/XXXXX-data-db/build/deployit-manifest.xml

Or maybe I'm wrong?
Do you have any suggestion?

Thanks

Since I upgraded to Gradle 6.5, I get the following warnings:

The AbstractArchiveTask.extension property has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the archiveExtension property instead. See https://docs.gradle.org/6.5/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.html#org.gradle.api.tasks.bundling.AbstractArchiveTask:extension for more details.

Property 'darTask' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.5/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

I assume these need to be fixed as it will stop working with Gradle 7.0.

I submitted a PR in relation to #11, which we have been running so far but we finally had time to upgrade our plugin to the official 5.0 and we are experiencing that the deployment to xl deploy fails due to An established connection was aborted by the software in your host machine.

The difference between 5.0 and our plugin is that the remote-booter has been upgraded.
This has been due to that when I submitted the PR the build failed due to some class version that did not match and a suggestion was to change the version of the remote-booter dependency.

This seems to causing the issue.

We have reverted to our own version of 5.0, however it will probably be better to fix the the issue why it is not building with the PR I submitted.

I have attached the stacktrace to diagnose the issue further.

org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:174)
at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:478)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:422)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1712)
at com.xebialabs.deployit.jetty.MaintenanceModeFilter.doFilter(MaintenanceModeFilter.java:77)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:215)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:200)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:121)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at com.xebialabs.license.LicenseValidationFilter.doFilter(LicenseValidationFilter.java:61)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at com.xebialabs.deployit.jetty.NoOptionsFilter.doFilter(NoOptionsFilter.java:24)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at com.xebialabs.license.LicenseValidationFilter.doFilter(LicenseValidationFilter.java:61)
at com.xebialabs.deployit.FlexLicenseValidationFilter.doFilter(FlexLicenseValidationFilter.java:41)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:56)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1182)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Unknown Source)
Caused by: com.thoughtworks.xstream.io.StreamException:
at com.thoughtworks.xstream.core.util.QuickWriter.flush(QuickWriter.java:77)
at com.thoughtworks.xstream.io.xml.PrettyPrintWriter.endNode(PrettyPrintWriter.java:322)
at com.thoughtworks.xstream.io.WriterWrapper.endNode(WriterWrapper.java:37)
at com.thoughtworks.xstream.io.path.PathTrackingWriter.endNode(PathTrackingWriter.java:48)
at com.xebialabs.xltype.serialization.xstream.Converters.writeConfigurationItem(Converters.java:48)
at com.xebialabs.xltype.serialization.xstream.ConfigurationItemMarshallingStrategy$ConfigurationItemMarshaller.start(ConfigurationItemMarshallingStrategy.java:41)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1067)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1056)
at com.thoughtworks.xstream.XStream.toXML(XStream.java:1029)
at com.xebialabs.xltype.serialization.xstream.XStreamReaderWriter.writeTo(XStreamReaderWriter.java:168)
at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:473)
... 73 common frames omitted
Caused by: org.eclipse.jetty.io.EofException: null
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:199)
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:420)
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:313)
at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:140)
at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:730)
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224)
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:518)
at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:719)
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:775)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:235)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:219)
at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:355)
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.flush(OnCommittedResponseWrapper.java:513)
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.flush(OnCommittedResponseWrapper.java:513)
at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.flush(HttpServletResponseWrapper.java:52)
at org.jboss.resteasy.util.CommitHeaderOutputStream.flush(CommitHeaderOutputStream.java:78)
at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
at sun.nio.cs.StreamEncoder.flush(Unknown Source)
at java.io.OutputStreamWriter.flush(Unknown Source)
at com.thoughtworks.xstream.core.util.QuickWriter.flush(QuickWriter.java:75)
... 90 common frames omitted
Caused by: java.io.IOException: An established connection was aborted by the software in your host machine
at sun.nio.ch.SocketDispatcher.writev0(Native Method)
at sun.nio.ch.SocketDispatcher.writev(Unknown Source)
at sun.nio.ch.IOUtil.write(Unknown Source)
at sun.nio.ch.SocketChannelImpl.write(Unknown Source)
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:179)
... 110 common frames omitted

In fact that java 11 is now long time support version, plugin should migrate to gradle wrapper version 5+
Expectations:

• Removed deprecated api
• Fixed tests

I need to include all jar files inside a folder.

${artifact(project.file("$project.buildDir/jars"))}

The artifact function returned the correct path (e.g. artifacts/[module]/build/jars), but it copied the files wrong. All the jar files were copied into "artifacts/[module]/build", and they were all named "jars" (though they were not the same file, file sizes were correct despite the wrong file name).

I think the bug is in DarTask.groovy:194. There, when calling f.getName(), f is not a file but a directory.

Hello,

we encounter an issue while using the 0.2.2 version of the gradle plugin :
17:24:15.010 [ERROR] [org.gradle.BuildExceptionReporter] at com.xebialabs.gradle.xldeploy.DarTask.copy(DarTask.groovy:54) 17:24:15.011 [ERROR] [org.gradle.BuildExceptionReporter] at com.xebialabs.gradle.xldeploy.DarTask.copy(DarTask.groovy:54) 17:24:15.011 [ERROR] [org.gradle.BuildExceptionReporter] at com.xebialabs.gradle.xldeploy.DarTask.copy(DarTask.groovy:54) 17:24:15.011 [ERROR] [org.gradle.BuildExceptionReporter] at com.xebialabs.gradle.xldeploy.DarTask.copy(DarTask.groovy:54) 17:24:15.011 [ERROR] [org.gradle.BuildExceptionReporter] at com.xebialabs.gradle.xldeploy.DarTask.copy(DarTask.groovy:54)

i tried to use -d and --stacktrace, but i can't get more informations.

Command used : gradle jar deploy
gradle version : 2.11

src/main/dar/manifest.xml content 👍
<?xml version="1.0" encoding="UTF-8"?> <udm.DeploymentPackage version="12" application="DPY/${project.name}"> <deployables> <file.File name="testPackage" file="${artifact(project.jar)}"> <targetPath>/tmp/</targetPath> </file.File> </deployables> </udm.DeploymentPackage>

Regards,
Guillaume

We have a case where a build pipeline is used to produce a DAR file doesn't have access to XL Deploy. We publish the DAR file to a Maven repository and would like to be able to provide our customer with a separate small build.gradle that downloads the release from Maven repo and then upload to XL Deploy and optionally trigger a deployment.

So it would be useful to have an 'upload task' that can be configured with a path to dar file and the credentials of XL Deploy.

Does the plugin support windows.Msi deployables?
If I use a manifest like this:
<?xml version="1.0" encoding="UTF-8"?> <udm.DeploymentPackage application="OurApplication" version="${noSnapshot("(package_version)s")}"> <orchestrator> <value>sequential-by-composite-package</value> </orchestrator> <deployables> <windows.Msi name="OurApplication-64bit" file="Setup/Release/OurApplication-64bit.msi"> </windows.Msi> </deployables> </udm.DeploymentPackage>
,
the resulting dar package does not contain the .msi .

Hello, I am seeing this issue in jenkins. Need help here.

Info: Package application Applications/Childsupport/CS-Calculator, version Calculator-48
Info: Application Applications/Childsupport/CS-Calculator has been packaged /usr/devopsTools/Jenkins_Slave3/workspace/XL_Child-Support/CS-Calculator/deployitpackage/CS-Calculator-Calculator-48.dar
java.lang.IllegalStateException: Failed to create directory within 10000 attempts (tried 1562589097891-0 to 1562589097891-9999)
at com.google.common.io.Files.createTempDir(Files.java:600)
at com.xebialabs.deployit.ci.RemoteAwareLocation.getRemoteAwareLocation(RemoteAwareLocation.java:24)
at com.xebialabs.deployit.ci.GeneratedLocation.getDarFileLocation(GeneratedLocation.java:43)
at com.xebialabs.deployit.ci.JenkinsImportOptions.getDarFileLocation(JenkinsImportOptions.java:53)
at com.xebialabs.deployit.ci.DeployitPerformer.doPerform(DeployitPerformer.java:92)
at com.xebialabs.deployit.ci.DeployitNotifier.perform(DeployitNotifier.java:132)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1073)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
at hudson.model.Run.execute(Run.java:1841)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
ERROR: Error when importing dar file : Failed to create directory within 10000 attempts (tried 1562589097891-0 to 1562589097891-9999)
Build step 'Deploy with XL Deploy' marked build as failure
Finished: FAILURE

When gradle to 4.0 the gradle xld plugin caused the following exception:

Caused by: org.gradle.api.GradleException: You cannot add child specs at execution time. Consider configuring this task during configuration time or using a separate task to do the configuration.
at org.gradle.api.tasks.AbstractCopyTask$1.childSpecAdded(AbstractCopyTask.java:66)
at org.gradle.api.internal.file.copy.DefaultCopySpec.fireChildSpecListeners(DefaultCopySpec.java:191)
at org.gradle.api.internal.file.copy.DefaultCopySpec.access$000(DefaultCopySpec.java:55)
at org.gradle.api.internal.file.copy.DefaultCopySpec$2.visit(DefaultCopySpec.java:184)
at org.gradle.api.internal.file.copy.DefaultCopySpec.visit(DefaultCopySpec.java:197)
at org.gradle.api.internal.file.copy.DefaultCopySpec.addChildSpec(DefaultCopySpec.java:181)
at org.gradle.api.internal.file.copy.DefaultCopySpec.addChildSpec(DefaultCopySpec.java:161)
at org.gradle.api.internal.file.copy.DefaultCopySpec.addChild(DefaultCopySpec.java:151)
at org.gradle.api.internal.file.copy.DefaultCopySpec.into(DefaultCopySpec.java:230)
at org.gradle.api.internal.file.copy.DefaultCopySpec.into(DefaultCopySpec.java:222)
at org.gradle.api.file.CopySpec$into$0.call(Unknown Source)
at com.xebialabs.gradle.xldeploy.DarTask.processManifest(DarTask.groovy:76)
at com.xebialabs.gradle.xldeploy.DarTask.darCopy(DarTask.groovy:58)

Hi!

gradle-xld-plugin wants remote-booter:2014.10 but I see only 2014.7.4 /opt/xebia/xl-deploy/lib/local-booter-2014.7.4.jar in my XLD installation. Google didn't help
Do you have any suggestion how can I run this plugin?

Thanks!

We have run into issues with the 0.5.0 release updated to reference com.xebialabs.deployit.engine:remote-booter:2017.5.0 causing disconnects after the DAR package is uploaded to xl-deploy but before the deploy task is created on xl-deploy version 6.0.3. In a support ticket with XebiaLabs https://support.xebialabs.com/hc/en-us/requests/10044 we were informed that the remote-booter library is an "There is no publicly supported interface to the remote booster plugin. There is nothing in the design of this library to facilitate its use here. The original author chose to do so but it is not supported. There is no documentation of it's use (and that is not unintentional) so there is no documentation about compatibility." XebiaLabs also gave us the following compatible version mappings:

• 2017.5.0 is available since XL Deploy 7.1.0
• remote booter version 2016.2.3 --> XLD 6.0.3
• remote booter version 2016.2.5 --> XLD 6.0.5

We have resolved this issue by recompiling gradle-xld-plugin against 2016.2.5 which shipped with xl-deploy 6.0.5 (we also validated that it is working with xl-deploy 6.0.3).

We would like to use this issue to discuss possible ways to address the support and version compatibility issues with the community plugin, xl-deploy releases and the remote-boot library.