antibm-mobilefirstworklight-server

IBM Worklight 6.0 - Unable to deploy adapter and app with ant task

I am attempting to do a simple build and deploy of a worklight adapter using an Ant Task.

Here is the task: 

<?xml version="1.0" encoding="UTF-8"?>  
<project name="Project" default="buildAndDeployAdapters" basedir=".">  
    <taskdef resource="com/worklight/ant/defaults.properties">  
        <classpath>
            <pathelement location="C:\Users\IBM_ADMIN\DownloadDirector\CIN0VEN\worklight-ant.jar"/>  
        </classpath>  
    </taskdef>  

    <target name="buildAndDeployAdapters">
        <adapter-builder folder="adapters\ProjectAdapter" destinationfolder="bin"/>
        <adapter-deployer worklightserverhost="http://localhost:10080" deployable="bin\ProjectAdapter.adapter" />
    </target>
</project>

The build succeeds, but when the deploy occurs I get the error message:

build.xml:11: java.lang.StringIndexOutOfBoundsException: String index out of range: -1

If I go to http:// localhost:10080 on my browser, I successfully hit the Web Sphere page. I have verified that the path to the ProjectAdapter.adapter is correct as well. I have tried deploying my application the same way and it also gets the same error. I can deploy in eclipse just fine by right clicking the adapter or application and deploy.

I'm using the worklight Eclipse plugin, version 6.0.0.20130701-1413. I recently upgraded from the worklight free developer editon to the Enterprise Edition in order to do these build tasks. What could be the problem? Perhaps I did not upgrade properly? My goal is to run some other tasks before I build and deploy, but first I need to get build and deploy working.

Thanks!

Solution

  • As mentioned by tik27, in Worklight 6.0 there is now also a default context root in the worklightserverhost path.

    The context root by default is the project name. For example: 

    <adapter-deployer worklightserverhost="http://localhost:10080/mytestproject" deployable="bin\ProjectAdapter.adapter" />

    The documentation does not yet state this, but it has been fixed internally and pending re-publication.

    Also see: