Running vert.x 2.0 - could not find or load main class

[Scott Brown]

Was able to build vertx 2.0 snapshot after Tim's help.  Now when I run it, I'm getting 'could not find or load main class'.

Digging through the vertx.bat script, my classpath is set to:

.;C:\Program Files (x86)\Java\jre7\lib\ext\QTJava.zip;C:\repos\vert.x\build\vert.x-2.0.0-SNAPSHOT\bin\..\lib\*;C:\repos\vert.x\build\vert.x-2.0.0-SNAPSHOT\bin\..\conf

[Scott Brown]

(used gradle assemble to build the 'build' directory)

[Tim Fox]

What are you trying to run here?

What command line did you use?

[Scott Brown]

Sorry, previously I was executing vertx with 1.3.1.

I have now built the 2.0 SNAPSHOT.  I ran gradle assemble to build the executables.  I'm trying to just run vertx version from the command prompt to see if it works but it's not finding the main class.

[Tim Fox]

On 10/05/13 15:36, Scott Brown wrote:
> Sorry, previously I was executing vertx with 1.3.1.
>
> I have now built the 2.0 SNAPSHOT. I ran gradle assemble to build the
> executables.

./gradlew assemble just constructs the Maven artifacts - it does not
build a distro, nor install one.

if you want to build a distro use:

./gradlew dist

This will create the distro (.zip and .tar.gz) in build/distributions

These are the things that you would normally download from the website
and install.

So... you can install them as normal (unzip them somewhere, and set your
to PATH to point at the bin directory).

Then you'll be able to do

vertx version

Alternatively you can set your PATH to point to
build/vert.x-2.0.0-SNAPSHOT/bin which is where the exploded distro is
built, then you won't need to reinstall it every time you build a distro.

BTW, don't use 'gradle', use './gradlew' (or gradlew.bat if you're
unfortunate enough to be on Windows)

> I'm trying to just run *vertx version* from the command

[Scott Brown]

Building the distro and pointing my PATH and VERTX_HOME to that give me the same error as when I was using build\bin.  I used gradlew.bat dist.

Is there somewhere I can just grab the distributable?

I just recently left *NIX world and now am forced to work in Windows, it is painful.

On Friday, May 10, 2013 10:28:39 AM UTC-4, Scott Brown wrote:

[Tim Fox]

On 10/05/13 15:51, Scott Brown wrote:
> Building the distro and pointing my PATH and VERTX_HOME to that give me the
> same error as when I was using build\bin. I used gradlew.bat dist.
>
> Is there somewhere I can just grab the distributable?
>
> I just recently left *NIX world and now am forced to work in Windows, it is
> painful.

I feel your pain.

tbh we haven't tested it on Windows yet (none of us use Windows), but we
will do this before 2.0 is out. Perhaps there is a genuine problem with
the Windows classpath....

Can you run a Linux VM on your windows box?

>
> On Friday, May 10, 2013 10:28:39 AM UTC-4, Scott Brown wrote:
>> Was able to build vertx 2.0 snapshot after Tim's help. Now when I run it,
>> I'm getting 'could not find or load main class'.
>>
>
>
>> Digging through the vertx.bat script, my classpath is set to:
>>
>>> .;C:\Program Files (x86)\Java\jre7\lib\ext\QTJava.zip;C:\repos\vert.x\

[Scott Brown]

Yes, I have an Ubunutu VM.  I can attempt to run it there and see how it goes.

Is it possible to run a module written in 2.0 using vertx.1.3.1?

I had a module working in 1.3.1 just using a rigged-up maven project.

Now I converted my module to the gradle vertx mod template, and converted all the code in my module to 2.0.

When I attempt to deploy this module (running with vertx 1.3.1) I get this error:  java.lang.ClassCastException: com.soandso.SparqlService cannot be cast to org.vertx.java.deploy.Verticle

I'm assuming this is because I'm not running vertx 2.0, but I have been wrong from time to time : ).

[Tim Fox]

On 10/05/13 15:59, Scott Brown wrote:
> Yes, I have an Ubunutu VM. I can attempt to run it there and see how it
> goes.
>
> Is it possible to run a module written in 2.0 using vertx.1.3.1?

No, Vert.x 1 and 2 modules are incompatible

[Scott Brown]

Okay, well I'll move everything over to my Linux VM and let you know how that goes.

[Scott Brown]

It works fine on Ubuntu.  So it seems there is a classpath error on the Windows .bat file.  What does it need in the classpath, just what is packaged in the lib directory of the distribution?

[Scott Brown]

I'm isolating the problem, I'll let you know what the problem was.

[Scott Brown]

Got the vertx.bat working, Changes will be bolded and will have a @rem Windows 7 change remark.  Others may need more changes, specifically quotes around environment variables if their mapped paths have spaces in them.

@if "%DEBUG%" == "" @echo off
@rem ##########################################################################
@rem
@rem  vertx startup script for Windows
@rem
@rem ##########################################################################

@rem Set local scope for the variables with windows NT shell
if "%OS%"=="Windows_NT" setlocal

@rem Add default JVM options here. You can also use JAVA_OPTS and VERTX_OPTS to pass JVM options to this script.
set JVM_OPTS=

@rem Windows7 change - had to remove double quotes here or it was evaluating to """"
set JMX_OPTS=
@rem To enable JMX uncomment the following
@rem set JMX_OPTS=-Dcom.sun.management.jmxremote -Dvertx.management.jmx=true -Dhazelcast.jmx=true

set DIRNAME=%~dp0
if "%DIRNAME%" == "" set DIRNAME=.
set APP_BASE_NAME=%~n0
set VERTX_HOME=%DIRNAME%..

@rem Find java.exe
if defined JAVA_HOME goto findJavaFromJavaHome

set JAVA_EXE=java.exe
%JAVA_EXE% -version >NUL 2>&1
if "%ERRORLEVEL%" == "0" goto init

echo.
echo ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
echo.
echo Please set the JAVA_HOME variable in your environment to match the
echo location of your Java installation.

goto fail

:findJavaFromJavaHome
set JAVA_HOME=%JAVA_HOME:"=%
set JAVA_EXE=%JAVA_HOME%/bin/java.exe

if exist "%JAVA_EXE%" goto init

echo.
echo ERROR: JAVA_HOME is set to an invalid directory: %JAVA_HOME%
echo.
echo Please set the JAVA_HOME variable in your environment to match the
echo location of your Java installation.

goto fail

:init
@rem Add module option to commandline, if VERTX_MODS was set
if not "%VERTX_MODS%" == "" set VERTX_MODULE_OPTS="-Dvertx.mods=%VERTX_MODS%"

@rem Configure JUL using custom properties file
@rem Windows 7 change - %APP_HOME% was used previously, it was not resolving to the right location
if "%VERTX_JUL_CONFIG%" == "" set VERTX_JUL_CONFIG=%VERTX_HOME%\conf\logging.properties

@rem Get command-line arguments, handling Windowz variants

if not "%OS%" == "Windows_NT" goto win9xME_args
if "%@eval[2+2]" == "4" goto 4NT_args

:win9xME_args
@rem Slurp the command line arguments.
set CMD_LINE_ARGS=
set _SKIP=2

:win9xME_args_slurp
if "x%~1" == "x" goto execute

set CMD_LINE_ARGS=%*
goto execute

:4NT_args
@rem Get arguments from the 4NT Shell from JP Software
set CMD_LINE_ARGS=%$

:execute
@rem Setup the command line

@rem Windows 7 change - Had to add quotes around classpath because my existing path contained spaces, may be necessary for VERTX_HOME also if yours contains spaces
set CLASSPATH="%CLASSPATH%";%VERTX_HOME%\lib\*;%VERTX_HOME%\conf

@rem Execute vertx
"%JAVA_EXE%" %JVM_OPTS% %JMX_OPTS% %JAVA_OPTS% %VERTX_OPTS% %VERTX_MODULE_OPTS%  -Djava.util.logging.config.file="%VERTX_JUL_CONFIG%" -Dvertx.home=%VERTX_HOME% -classpath %CLASSPATH% org.vertx.java.platform.impl.cli.Starter %CMD_LINE_ARGS%

:end
@rem End local scope for the variables with windows NT shell
if "%ERRORLEVEL%"=="0" goto mainEnd

:fail
rem Set variable VERTX_EXIT_CONSOLE if you need the _script_ return code instead of
rem the _cmd.exe /c_ return code!
if  not "" == "%VERTX_EXIT_CONSOLE%" exit 1
exit /b 1

:mainEnd
if "%OS%"=="Windows_NT" endlocal

:omega

On Friday, May 10, 2013 10:28:39 AM UTC-4, Scott Brown wrote:

[Arnold Schrijver]

Had the same problem on Win7 today.

The solution of Ducky Hong in this post solved the issue for me.

[Scott Brown]

I saw that also.  Was almost all spaces & quotes issues.  Except for %APP_HOME% not resolving for me properly.

[Thorsten Marx]

Same problem with vert.x-2.0.0-beta2. You startscript works fine, every windows user will love you for that. 

Maybe you should create a pull request for that.

[Tim Fox]

I don't really understand what change is required here.

Can someone open a github issue and attach a patch, or a PR would be even better...

[Kutý Michael]

I created git issue #615

Dne úterý, 21. května 2013 12:32:24 UTC+2 Tim Fox napsal(a):

[Scott Brown]

Sorry I didn't write a 'complete' fix, just enough to fix mine.  The windows .bat file for vertx basically needs to account for 'quoting' issues on Windows.  Also in my post above (the one with my fix) there is one environment variable I changed (noted in comments in my post) because the original variable was not resolving to the proper location, it was a directory short basically.