Starting with Vert.x 3 – Creating a new project
April 11, 2015

These are my first impressions on what have changed in Vert.x 3 from a regular java developer perspective.

Vert.x 3 has ripped off the old modules concepts in favor of a more straightforward approach. Now you don’t need to create a .zip file with an structure to deploy your application, instead, you run your application inside vert.x however you want. These is a great power and at first I found myself a little lost.

You can still download a vert.x distribution but, with the current state of the platform, I see it like an easy way to start making experiments (even in the many languages vert.x support) and it’s not necessary anymore for productive environments.

In Vert.x 3 you create your own main function, invoke a Vert.x factory, and voilĂ , you have the whole platform there to serve you. Indeed, you can see the io.vertx.core.Starter class, which is invoked by the executable bin/vertx in the distribution, to see there is nothing but CLI args parsing and building configurations for the factory I mentioned before.

From the v2 era I liked to have a main point written in javascript to deploying all my java verticles. I though it as my init script so it made sense to have it in an scripting language, I didn’t want to lose that. So now it’s my responsibility to create this structure. A few lines of code is worth a thousand words:
(Deprecated: see Update section below)

    public class Launcher {
        public static void main(String[] args) {
            Logger vertxLogger = LoggerFactory.getLogger(Launcher.class.getName());
            Vertx vertx = Vertx.vertx();
            vertx.deployVerticle("main.js", event -> {
                if (event.succeeded()) {
          "Your Vert.x application is started!");
                } else {
                    vertxLogger.error("Unable to start your application", event.cause());

            Runtime.getRuntime().addShutdownHook(new Thread() {
                public void run() {
                    final CountDownLatch latch = new CountDownLatch(1);
                    vertx.close(ar -> {
                        if (ar.succeeded()) {
                  "Your Vert.x application is stopped!");
                        } else {
                            vertxLogger.error("Failure in stopping Vert.x", ar.cause());
                    try {
                        if (!latch.await(2, TimeUnit.MINUTES)) {
                            vertxLogger.error("Timed out waiting to undeploy all");
                    } catch (InterruptedException e) {
                        throw new IllegalStateException(e);

In line 5 I deploy my main verticle.
Lines 13-32 are stolen from io.vertx.core.Starter to properly shutdown the application.

For this to run you just need a few dependencies: io.vertx:vertx-core:jar:3.0.0-milestone4:compile and io.vertx:vertx-lang-js:jar:3.0.0-milestone4:runtime

Packing your application

Now it’s just a matter of packing the application to make it runnable. There is a movement loving the concept of fatJar, I personally dislike it for various reasons, one of them is that I see it completely unnecessary, we are advanced Java developers, man up, setup you classpath and invoke the Main Class as the good lord says (well, that was too much).

In Maven this is extra easy, you just need to properly setup the maven-jar-plugin to write the MANIFEST and the maven-assembly-plugin to load an assembly descriptor. Then you can have a simple script for running it without even having to remember the name of your main jar. I use something like this:

    #!/usr/bin/env bash
    DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
    java -jar $DIR/libs/${}.${project.packaging} $@

Here is a minimal pom.xml briefing all the above ideas:

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns=""



And also the dist.xml:

    <assembly xmlns=""

With this initial configuration, you run mvn package and you’ll got a tarball into the target/ folder, untar it and you’ll have a nice running script for your whole application.

Bonus track

I prefer to use Logback as my logging system, and in the old days we had to modify the vert.x distribution and the executable to get this support.
Nowadays you just add System.setProperty(LoggerFactory.LOGGER_DELEGATE_FACTORY_CLASS_NAME, SLF4JLogDelegateFactory.class.getName()); as the first line of your main, add the ch.qos.logback:logback-classic:jar:1.1.3:runtime dependency and you are there.
For the extra lazy, here is a simple logback.xml:

      <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender" level="INFO">
          <pattern>[%-5level] %logger{15} - %msg%n</pattern>
      <logger name="io.vertx" level="INFO">
        <appender-ref ref="STDOUT" />
      <logger name="com.hazelcast" level="ERROR">
        <appender-ref ref="STDOUT" />
      <logger name="io.netty.util.internal.PlatformDependent" level="ERROR">
        <appender-ref ref="STDOUT" />
      <root level="INFO">

I also like to have an user accessible logging configuration, for this, you must add the following to the dist.xml file


and modify the java invocation line in to include -Dlogback.configurationFile=file:$DIR/logback.xml

I hope you find this useful and enjoy the great things Vert.x 3 has to offer.


I’ve been thinking and I rather see unnecessary to have my own main class which at the end will imitate the provided io.vertx.core.Starter. So I’ve simplified my initial deployment removing all references to my custom mainClass and with this

    #!/usr/bin/env bash
    DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
    java -Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.impl.SLF4JLogDelegateFactory \
         -Dlogback.configurationFile=file:$DIR/logback.xml \
         -classpath "$DIR/libs/*" io.vertx.core.Starter run main.js \
         -conf $DIR/conf.json

Also, if you want to run your application using maven (useful for debugging) you just need to configure the org.codehaus.mojo:exec-maven-plugin like this: