ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Fetzer <>
Subject Wierdness With Java Task
Date Fri, 02 Oct 2009 16:46:10 GMT
I have a <java> task that I'm using as such on two separate machines: 

       <java jvm="${java.bin}/java.exe" classname="org.eclipse.core.launcher.Main"
            fork="true" failonerror="true" maxmemory="512m">
            <env key="Path" 

            <arg value="-noupdate"/>
            <arg value="-data"/>
            <arg value="${workspace.dir}"/>
            <arg value="-application"/>
            <arg value=""/>
            <arg value="-project"/>
            <arg value="${project}"/>
            <arg value="-action"/>
            <arg value=""/>

Up until this point, the log shows identical (version of ant, version of java, line for line
log file is identical).  In fact, both machines were built IDENTICALLY to a T.  When running
this task, however, one of the machines claims:

     [echo] Publishing projects to build EAR.
     [java] Executing 'C:\IBM\WebSphere\AppServer\java\bin\java.exe' with arguments:
     [java] '-Xmx512m'
     [java] '-classpath'
     [java] 'C:\Versata\BRE-6.3\workbench\startup.jar'
     [java] 'org.eclipse.core.launcher.Main'
     [java] '-noupdate'
     [java] '-data'
     [java] 'C:/VersataWorkbench/workspace'
     [java] '-application'
     [java] ''
     [java] '-project'
     [java] 'rossApp'
     [java] '-action'
     [java] ''
     [java] The ' characters around the executable and arguments are
     [java] not part of the command.
     [java] Setting environment variable: Path=C:\IBM\WebSphere\AppServer\java\jre\bin;C:\Versata\BRE-6.3\websphere61\VLS\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Versata\BRE-6.3\workbench\plugins\\DLL
     [java] Unable to resolve VLS_LOGS_ROOT from JNDIName: null
     [java] VLS_LOGS_ROOT = C:\Versata\BRE-6.3\websphere61\VLS\bin\logs
C:\Versata\BRE-6.3\websphere61\VLS\bin\lightsout.xml:270: Java returned: 13
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 at java.lang.reflect.Method.invoke(

And on the other machine, it rolls right through.  Line 270 of lightsout.xml is:

 fork="true" failonerror="true" maxmemory="512m">

Any help with how I can trouble-shoot this dilemma?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message