Which projects aren't public?

• Vaadin Charts UI
• Vaadin responsive application frame
• Application client
• Application server
• Application Services
• JavaFX mobile UI
• Oracle Forms extension

We provide snapshot and release artifacts. All other - public - projects are available via maven central as release or snapshot artifacts.

• JVx
• JVx EE
• Vaadin UI
• JavaFX UI
• Headless UI
• Online help
• JVx mobile

Our private Maven repository is available on a subscription basis. This doesn't mean that our private projects aren't open source projects, but we don't offer snapshot or release artifacts for them!

Shouldn't maven solve all dependency problems? I didn't try to fix problems with Eclipse because it could be a maven plugin problem. So I tried maven itself with jdk 1.5 and some minutes later I got other exceptions because Twitter4j source was written with Java 6 syntax (@Override with interface methods).
So I had to use Java 6 with 1.5 target option... After modifying pom.xml of twitter4j-core, the build had another problem: All test cases failed . So I had to use the command-line property -Dmaven.test.skip=true to ignore unit tests.

Finally I got my 1.5 compatible Twitter4j library.

But it was an awful task because maven bundled with Eclipse didn't work as expected. It's horrible if tools that should save time, waste time. I still don't like maven. IMHO it's still to complex compared to other build tools.
A build tool shouldn't be as complex as developing software.

Nowadays everything has to work with our IDEs, but what happens if it doesn't?

I'm a researcher and love solving problems but is it that complex to keep things simple?
Software has to be simple to help us and we - developers - have to write simple software/frameworks/libraries.

Instead of creating simple software, many developers try to write millions LoC. Don't do that because no one can handle such code-bases in the future.

Just sayin'

Simply create a new maven project (my IDE is Eclipse) based on JVx Archetype 1.2.0. This archetype references JVx 1.2. Older versions are not compatible with Vaadin UI 1.0 - because of new features in JVx' launcher interface. In order to use Vaadin for JVx applications, add following dependencies to the pom.xml of your server project:

Set the global property in parent project pom.xml:

Because Vaadin runs on server-side, our client has to be deployed on server-side as well. Change pom.xml of your war project:

This is not a perfect solution because jvxclient.jar will be added. This lib is not necessary because jvxall.jar is already available - but also not a problem!

The last step is the integration of JVx' VaadinUI. There are many solutions to integrate external libraries but maven is not a friend of external libraries. Using system scrope is evil and such libraries won't be added to war files. Deploying external jars to a local maven repository works but why should we do that? I did decide to use sort of a local maven repository placed in my project with following file structure in my server project:

The integration in pom.xml of server project:

Finally we need additional dependencies (server project):

The last integration step is the modification of web.xml in our war project:

That's it.

Use the war project together with an application server in Eclipse and enter http://localhost/myproject/vaadinui/ in a web browser to start your application with VaadinUI - with debugging support. Create a war file, deploy it and it will work without problems.

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:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

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

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

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

Repository Id, URL

${mvn.id} = sonatype-nexus-staging
${mvn.url} = https://oss.sonatype.org/service/local/staging/deploy/maven2

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:

We configured the proxy via ant build.xml

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!

The project contains a simple ANT build with two important targets. The first is start.complete. This target creates the archetype archive and deploys it to our sonatype repository. The second target is start.recreate. This target is very cool because it cleans the archetype project (mvn clean), installs the archetype in your local repository (mvn install) and creates a new project based on the installed archetype (mvn archetype:generate).

Usually, you have to use scripts, the command-line or external tools to do all your tests. We automated the whole process. Our build uses the maven integration for ant.

The integration tasks were a little bit strange but after some tests we made it working. The trick was that the build.xml and pom.xml files must be stored in separate folders. Otherwise project creation based on an archetype didn't work.

The archetype:

Use your preferred IDE to create your JVx project. The archetype will create 4 new Maven projects. The first project is the master project. It references 3 modules. The first module is the client, the second one is the server and the third one is a war module.

The client module/project contains all UI relevant classes like Application and Screens. The server module/project contains the business logic of your application. The war module/project creates a full functional web application archive (war) and allows you to publish your application with Eclipse WTP.

The client project contains a preconfigured JVx Application with one simple work-screen. It contains the class MainApplication which contains a main method. Simply start MainApplication and login with username (admin) and password (admin). The application doesn't need a database because it uses a XmlSecurityManager and an AbstractMemStorage. It only is an example application and not for production use!

Use the war project to create deployable war files. We've used it successfully with e.g. Tomcat. After deployment, simply open the application URL - http://localhost/firstapp - (replace firstapp with your application name) and login. The application is also available via JNLP - http://localhost/firstapp/application.jnlp.

If you want to test your desktop application with your application server, e.g. Tomcat with Eclipse WTP, simply change the connection in your application. The default connection is a DirectServerConnection. This means that client and server run in the same VM. If you change the connection to HttpConnection, a remote server will be used. An example is available in the application source code.

The JVx Application Archetype creates a full functional 3tier application. It's preconfigured to run as desktop application and with an application server like Tomcat. Don't think about project creation and directory conventions. It simply works!

Have a look at an example project:

Standard application

Eclipse projects

Watch following video to see how it works:

Use following dependency in your pom.xml:

for your server project and following dependency:

for your client project.
The differences between jvxclient and jvxall are: The client does not contain server classes and is about 200Kb smaller.