This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

JVx Application Stack

We'll demonstrate the power of JVx in 3 minutes. One Application Framework, for all platforms.

You have never seen this before:

JVx Application Stack

Some details:

  • Simple deployment, because everything is contained in 1 war file
  • Developed with VisionX
  • Application runs as Java Desktop or Browser Application, as Web Application (HTML, CSS), on iOS or Android
  • Tested with iPhone, iPad, Android phone and tablet - as Web Application and native application

Do you know any other framework with comparable features. I think JVx is the only full stack application framework world-wide with single sourcing support for all platforms and devices - and it's open source.

JVx application with Vaadin launcher on iPad mini

For those, who don't know why the world needs single sourcing and only one framework for backend/frontend/mobile, we have a new use-case!

It's a new application that has different user groups. The first group sits in the backoffice and configures/crunches data. This user group needs a powerful backend application that supports fast (mass) data manipulation. The second user group are end users. This group needs a fancy web based application because an application must be cool and browser based (nowadays).

If you'll develop such an application with different UI frameworks and different technologies (Java, HTML, Javascript), different ORM tools, and for different browsers, clients, OS', you'll need time and a lot know how and maybe many developers.

Wouldn't it be great to use one framework that is powerful enough? The framework shouldn't be restrictive because we (software developers) want to be flexible and include our preferred libraries. No worries, JVx is flexible, small and is not restrictive.

If you develop your application with JVx, you have no problem with different platforms and devices. A JVx application runs as desktop application, in your browser as html application, on your mobile devices as html application and on your mobile devices as native application.

But enough advertising, lets look at the application. First, the backend application:

Video Backend

Video Backend

And the frontend, as video (video speed it's a little bit slow because it was recorded via Wi-Fi):

JVx frontend application

(The video shows our new maximize option, because mobile devices have limited space)

Above applications are not two separate applications. It's only one application with different users and roles. It looks different as desktop application than as web application. The only framework you need to know is JVx. It's not needed to be a html/javascript developer.

The framework is still simple and don't code multiple applications for different devices/platforms. Save time and be happy!

Discontinued QT UI

Our QT UI is 3 years old and was created as proof of concept for our generic UI. It's still 0.7 beta an we never had ideas for a real 1.0. Now we know that JVx' technology independent UIs work because we have different solutions with GXT and vaadin, mobile and our headless UI implementation.

We don't belive in QT Jambi as GUI toolkit and think the future of Java GUI toolkits is reserved for JavaFX or a completely new toolkit. Because of this fact, we discontinue our QT UI implementation and we'll clean our repository.

Project news

Some years ago, we started a project with the name OnlineHelp. It was used to create simple online help pages for applications. The project was implemented with GXT 2.1 and was really useful. It's still useful but the technology is old, and GXT is not our best friend. Of course newer versions are really fancy, but the license is not the best for commercial applications.

Some month ago, we decided to switch completely from GXT to vaadin - all our projects. The first project was our webUI and we make good progress. We're near to a first release, but we have no definite date for it (Q4/13 should be possible). The second project is the online help. We make good progress and have a first preview:

Online Help with vaadin

Online Help with vaadin

The style is similar to our new web application style but not a big change compared to our old online help, because our users like it:

Online Help with GXT

Online Help with GXT

The new style is fresh but not too much... We added some new features like full-text search and topic navigation (previous, next). It's a first preview and not more!

The project has now it's own project page and is not anymore a sub project of JVx. The license is still Apache 2.0.

Maven deployment via Ant

We are no Maven lovers, because it helps to forget how things work. But we think the dependency management is useful. It's great for developers who need specific library versions without managing them manually.

The user aspect is one thing, but nobody tells you that it's not trivial to release libraries. One problem is the pre-deployment process. Before you are able to deploy your jar files, you have to do a lot of things like GPG key generation, publishing GPG key, find the right repository, prepare your build, special pom cration and so on.

If you already have release builds with version numbers, javadoc and source archives, you'll save a lot of time. If you don't have complete and clean release builds - see you later.

Let's start with a good documentation about requirements:

Of course, it assumes that you'll use Sonatype as your repository, but all others are not too different.

This posting is not a complete documentation. It simply shows the problems we had.

Our simple pom files:
pom.xml (jvxall)
pom.xml (jvxclient)

The first is with dependencies and the second without, because our client doesn't have dependencies.

The real problems started with the integration in our ant script, because the documentation of Maven plugins were awful. It's easier to read the source code than to find out how plugins work. One example: Read following plugin documentation and tell me the valid values for "types" and "classifier". There are no examples on the page! Google around and copy/paste a little bit - awful!

Here's a working ant call

<typedef resource="org/apache/maven/artifact/ant/antlib.xml"
            classpath="${build}/maven/maven-ant-tasks-2.1.3.jar" />

<condition property="gpgexecutable"
     value="C:\Program Files\GNU\GnuPG\pub\gpg.exe" else="gpg">
        <os family="Windows" />

    <arg value="org.apache.maven.plugins:maven-gpg-plugin:1.4:sign-and-deploy-file" />
    <arg value="-Durl=${mvn.url}" />
    <arg value="-DrepositoryId=${}" />
    <arg value="-DpomFile=${maven.tmp}/jvxall/pom.xml" />
    <arg value="-Dfile=${mvn.jvx.jar}" />
    <arg value="-Dfiles=${mvn.jvx.sources.jar},${mvn.jvx.javadoc.jar}" />
    <arg value="-Dclassifiers=sources,javadoc" />
    <arg value="-Dtypes=jar,jar" />
    <arg value="-Pgpg" />
    <arg value="-Dgpg.executable=${gpgexecutable}" />

Above call submits e.g. jvx-1.1.jar, jvx-1.1-javadoc.jar and jvx-1.1-sources.jar to the repository.

Why one call instead of 3 separate calls, as described in the documentation?

Short: It's better :)
Long: It's better to submit all dependent files in one "maven session". Above call creates a new maven project and if you call this command per file, there's no logical connection between them. If you plan to deploy snapshot releases - forget it - it doesn't work with different calls because every upload gets a new buildnumber. But all files need the same buildnumber! Such deployments can't be used. If you read the Sonatype document, you saw that "deploy" task didn't deploy javadoc and sources! The "stage" task did. I'm not sure, but I think they had the same problem with separate uploads! Trust me, above call works with snapshots and final releases.

Our naming conventions

<property name="mvn.jvx.jar" value="${release}/maven/${}-${versionnumber}${maven.version.postfix}.jar" />
<property name="mvn.jvx.sources.jar" value="${release}/maven/${}-${versionnumber}${maven.version.postfix}-sources.jar" />
<property name="mvn.jvx.javadoc.jar" value="${release}/maven/${}-${versionnumber}${maven.version.postfix}-javadoc.jar" />

(${maven.version.postfix} is -SNAPSHOT for snapshot releases and empty for final releases)

Repository Id, URL

${} = sonatype-nexus-staging
${mvn.url} =

Other problems?

Proxy settings for Maven, Use an external GPG key, Autentication.

If you copy the following settings.xml to <users.home>/.m2 and modify it to fit your needs, it should solve all problems:

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


We configured the proxy via ant build.xml

<target name="proxy.check">
  <condition property="proxy.enabled">
      <socket server="" port="3128"/>

<target name="proxy" depends="proxy.check" if="proxy.enabled">
  <property name="" value=""/>
  <property name="proxy.port" value="3128"/>
  <property name="proxy.user" value=""/>
  <property name="proxy.pass" value=""/>
  <setproxy proxyhost="${}" proxyport="${proxy.port}"
            proxyuser="${proxy.user}" proxypassword="${proxy.password}"/>

Simply add "proxy" task as dependency of another task.

Maybe it's easier to release libraries with other build systems or maybe it works out-of-the-box with Maven itself, but the whole process is really bad.

Good luck!

JVx - Maven snapshots

We now provide our JVx nightly via Maven Snapshots. Our nightly build job automatically uploads new JVx snapshots. If you want to use the last JVx snapshot in your project, simply add:

    <name>Sonatype Snapshots</name>

to your pom.xml and set JVx' version to: 1.2_beta-SNAPSHOT.

If you use our new JVx archetype 1.1.9, simple change the version in the master project:


All SNAPSHOT versions contain debugging information. The release versions don't.

VisionX 1.2 Preview - Trial - available

The preview version of VisionX 1.2 is available as Trial version for your desktop. It offers all available features and shouldn't have any problems. The problems on MacOS are solved and it works without problems on Mac OS X 10.6, 10.7 and 10.8.

Simply download the preview version and try it on your own device!

If you already own VisionX, check your download area!

VisionX 1.2 Preview

VisionX 1.2 is planned for Q4/2013, but we'll show you some really cool features of the upcoming version. The current dev version is stable and we have a list of amazing productivity features.

  • An awesome feature is Undo/Redo for UI operations.

    This is a must for great UI design tools.

  • Xls Reporting is another key feature

    Simply create real XLS reports in seconds.

  • Xml Reporting is relevant for M2M communication and is included in VisionX
  • New Form validation support

    Create Forms and validate results with few mouse clicks.

  • Offline data gathering

    Create a XLS or XML report, add records to the created report and import the changed report into your application. This feature is amazing!

  • Liferay Portlet deployment

    Don't waste your time for portlet creation. Use VisionX and create a complete liferay portlet web application archive in seconds. Everything is pre-configured and ready-to-use. Let yourself be surprised.

  • You want More?

    Something like Mobile support and our new Vaadin UI... maybe in the next preview :)

Some impressions

Form validation

Form validation

XLS reporting

XLS reporting

Import report

Import report

ALL Features are available in our Cloud preview. Check it out today!

New project: toPDF

We tried to find a simple solution to convert MS Office files to pdf, without online services. We tried OpenOffice but the results were awful! There are a lot of free, and commercial, PDF printers available. But they are for desktops and a user has to print manually. We wanted a solution that works without user interaction.

There is a very useful open source project called PDFCreator. It also is a printer but has a useful API. The API is available via COM, which is not the best technology for Java, but it's also not bad.

We didn't find a ready-to-use solution for our idea and it shouldn't cost money. The solution had to be open source. We found some great commercial tools and SDKs but all of them were not cheap.

We spent some hours and used PDFCreator, Jacob and some other open source tools to create an "Online service for PDFCreator". The result of our work is toPDF.

What is toPDF?

It's a small library that allows conversion of files to PDF, via PDFCreator. It's also a web application that offers services for remote conversion via http. The application has a REST service and a simple servlet service.

Simply POST binary data via http request and receive a PDF in the response. The servlet supports multipart form-data and simple application/octet-stream as requests. The REST service also supports multipart form-data but also JSON requests.

A short example:

URL url = new URL(getServletService());

URLConnection ucon = url.openConnection();
ucon.setRequestProperty("Content-Type", "application/octet-stream");
ucon.setRequestProperty("Content-Disposition", "attachment; filename=\"Forms.docx\";");


byte[] byData = FileUtil.getContent(ucon.getInputStream());

or as Multipart:

MultipartUtil multipart = new MultipartUtil("UTF-8");
multipart.addDataPart("data", "Forms.docx",

byte[] byData =;

The conversion via PDFCreator works great, but not perfect. There are different problems with small page margins in Word documents, problems with OpenOffice documents, ...

The problem is not toPDF, because it works as good as PDFCreator does. If PDFCreator doesn't convert a document, toPDF has no chance to convert it.

We had problems with simple image conversions to PDF because default windows print dialog appeared and we didn't associate image extensions with another tool. We solved the conversion of images with iText instead of PDFCreator. Now it's possible to create PDFs from images very easily without pop-ups.


AGPL 3.0, because PDFCreator is licensed under GPL and iText is licensed under AGPL.

Used tools and libraries

toPDF is a mixture of different open source projects:

Apache commons FileUpload and IO


  • toPDF was written in Java, but the installation only makes sense on Windows (same requirements as PDFCreator)
  • Install PDFCreator (default desktop installation, with COM)
  • Deploy topdf.war on Tomcat or JBoss or your preferred Java application server. If your application server runs as windows service, be sure that it runs as OS user.