What is Codenvy?

In short, an IDE as online service or - with buzzwords - a cloud IDE. Some of the first questions were:

• Who needs a cloud IDE?
• Does a cloud IDE has enough features?

The answer to the first question could be: Developers without knowledge of environments. A cloud IDE simply runs, preconfigured with a compiler, preconfigured with a VCS, preconfigured build and or CI, deployment with one or two mouse clicks. If a developer does not know how he could configure all this things manually or with his IDE, he is a potential user of cloud IDEs.

As real software developer, you love your desktop IDE because it has all features... but some years ago, before we had Eclipse, Netbeans, IntelliJ or other IDEs, we used text editors and started compilers with scripts. I mean that features are relative because they will be more - it's a matter of time and number of users.

Another question was: Does it make sense to develop in the cloud?

It depends
If you develop web applications for end-users, you won't have problems with SLAs or confidentiality agreements? If you develop applications for business customers, you have to comply with contracts and data privacy. If you develop database applications, you must use a database available in the cloud.

If you develop in the cloud you should host everything in the cloud or make everything available in the cloud.

If you use a desktop IDE, you are the boss of updates and plugins. If you use a cloud IDE, the provider is the boss and updates whenever it's important or changes functionality whenever he wants. But you are always up-to-date.

An IDE in the cloud should be available on any device but is this important? Do you develop with your mobile device while sitting in your living room?

One fact is, that development in the cloud, is not as fast as local development (of course, if your environment is set up properly). Every task takes time and the performance of a Browser with Javascript is not really comparable to a native application, even if you you use Chrome. And another big disadvantage is that you can't change the environment. If you want to try different compilers, a different maven version or if you need a completely different project layout you'll have bad luck with cloud IDEs. If you want a new feature or different packages, you have to ask the provider for support.

I think that cloud IDEs are not an option for "pro" developers, but not every developer is a pro developer or needs much knowledge about complex environments. If a developer is more or less a "user", a cloud IDE will be an option.

What is a "user" developer?
(It's nothing bad!)

A developer without knowledge of environment configurations, without knowledge of build/CI systems. A developer that does not develop libraries or frameworks. Often a "pro" developer is also a "user" developer.

What has all this to do with JVx?

The creation of JVx applications should be as simple as possible and it should still be as simple as possible with cloud IDEs. Since we fully support Maven and have a JVx archetype, the creation of JVx applications - with standard IDEs - is very comfortable and super fast. We decided to try-out Codenvy because it looked very professional and had a clean GUI (similar to Eclipse). We tried Orion and had a bad feeling because it was a little bit hard to find out how it works, and finally it doesn't support pure Java projects (it currently supports JavaScript). The current Orion (2.0) IDE is more like a (very modern) remote file editor with JavaScript syntax highlighting and syntax check.

If a developer decides to use a cloud IDE, the IDE should be easy to use without a high learning curve (c'mon it's an IDE not a new programming language).

Our experiment with Codenvy

The IDE is free for open source projects (great for JVx) and so it was perfect for our tests. Our plan was to create a simple JVx application and run it in the cloud.

The IDE supports some project types and all are based on Maven because the build system uses Maven. It's possible to use preconfigured runtime platforms like Cloudbees. One problem is that it's not possible to create a project from scratch and add a target later. You must choose your target during project creation. Another problem is that it's not possible to use runtime platforms with Multi-module maven projects.

We decided to use the integrated runtime platform and didn't use another runtime platform. Not perfect but was OK for our tests.

We created a Multi-module Maven project and configured our modules. This was very easy with the IDE and build worked like a charm. Other problems were different restrictions dependent on your project type. It is not possible to Run a Multi-module maven project. It's possible to change the project type via properties, but that's not a good solution because it was not designed for tweaking. The next strange thing was that the UI has a lot of reload problems (endless reloads) and you have to close and open your project(s) to get full UI features for your project. The Run menu was not updated automatically.

The biggest problem was that the build system didn't build our project as usual or known from desktop IDEs. We had to find out how it works to deploy our application. The right build order solved our deployment issues.

At the end the deployment worked and it was possible to develop with the cloud IDE. One really big problem was that the integrated Java Editor did not show problems or code completition for our project. It worked with different project types but not with ours.

The IDE was easy to use because of many restrictions and assumptions how development should be, but it's absolutely not comparable with current desktop IDEs. Not because of missing features, it's because of given structures (predefined structures are important but sometimes they must be changeable).

At the end of our experiment, we had a working JVx application - developed in the cloud and deployed in the cloud.
Our project is available on github with some installation and usage instructions.

The result looks like:

JVx and Codenvy

The integration of Exchange servers is or could be very important for ERP applications. If you use Exchange to manage your contacts, appointments, task, etc. wouldn't it be great to manage or integrate your data in your application(s), directly without copying?

The problem is not the integration in your application, the problem is how you get data from your Exchange server. There are some commercial Java products available but you don't need commercial products since Microsoft offers EWS Java API. The API is very simple and communicates via SOAP to your Exchange server. The documentation is good for a quick start but you have to read source code if you want to know some details.

We made it simple for your JVx applications to integrate an Exchange server, because we did implement storages for Contacts and Contact folders (more will follow). With our storages it's a breeze to enrich your application. Create a storage in your life-cycle object like all other storages:

That's enough to read and write contacts.

If you work with contact folders, simply use our storage for it:

Our storages support load-on-demand and filtering via Exchange functionality. The folder storage supports shared folders!

It's straight forward to create a master/detail relation between folders and contacts. We developed a simple sample application.

Exchange Contact Management

And the best for last: Our storages are licensed under Apache 2.0.

The source code is available in our new project: JVx Storages.

If you want to know how we created our Maven Archetype for JVx, simply check the source code. The project is Open Source and licensed under Apache 2.0.

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.

JVx is available in all public Maven repositories and we added a JVx Application Archetype that creates the whole project structure for you. Use our archetype and you'll get a full configured JVx' Application - in few seconds.

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:

Have you ever tried to add/remove/change style sheets of Vaadin components dynamically, without css file modification? We didn't find suitable methods in Vaadin' standard components.

We miss methods like

in Vaadin. It's very easy to change style sheets with css files that are included in your project(s), but if you need a little bit more control... or must create dynamic applications - it's not possible out-of-the-box.

I'm not sure why there are no such methods, because GWT has all of them?

But no worries, with Vaadin 7 it's easy to add support for CSS manipulation. Simply use UI Extensions.

You'll find our CssExtension in our Vaadin UI project.

We're pleased to announce that JVx is available in the public maven repositories.

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.

What is JVx EE?

It is a small library that allows you to create backend applications for your frontends. Simply re-use your existing domain model and create a JVx application that uses a domain model instead of direct database connections.

It's licensed under Apache 2.0 and is available here.

What's new?

We reviewed the code and fixed some smaller bugs. We added an example application that shows how it works.

A short example

Session.java

Screen.java

Yesterday, we released a brand new version of JVx. The version number is now 1.1. We had some delays between 1.0 and 1.1 because we decided to do more researching as we originally planned. The 1.0 release was too stable and full featured because we only got positive feedback and some feature requests. Our product VisionX also uses JVx 1.0 and our customers had absolutely no problems.

Last year, we decided to open our nightly builds for everyone and because of our high quality standards, we had a new release every day. Some versions were broken but most versions were ready for production use. Of course, a nightly build is not an official release.

But now you are able to use the latest version of JVx as an official release and of course we offer full support.

We have a bunch of new features and smaller bugfixes. Many changes are related to other open source frameworks because we researched a lot of interesting libraries and frameworks. The famous ones are Javeleon and Vert.x.

So, what happened with JVx since 1.0?

• Improved REST support for all server-side life-cycle objects. It's possible to call actions and to access data (CRUD and metadata). The REST interface is using the same APIs and the same security settings as your web or desktop application. If you're using JVx, it's a task of 1 minute to bind external html5 clients.
  It's very easy to provide custom data for your customers, e.g. create a view in your database, use existing DAOs or dynamically create reports. You'll need about 5 minutes to provide new functionality.

• Full support for Vert.x

  We successfully used Vert.x http and socket server instead of Tomcat or JBoss. Simply use your existing applications and integrate them in your Vert.x environment. Don't change your application, simply use another technology.
  Simply use Vert.x event bus for asynchronous and live messages.

• Execute database procedures and functions like Java functions. Don't write many LoC for database access. We now offer input and output parameters as known from direct JDBC calls. We didn't reinvent the wheel but made JDBC a little bit easier to use.

  Standard JDBC procedure call:

  // Standard IN-OUT Parameter Test with plain JDBC
  Connection con = dba.getConnection();

  CallableStatement cstmt = con.prepareCall("{ call EXECPROCEDURE(?, ?, ?) }");
  cstmt.registerOutParameter(1, Types.DECIMAL);
  cstmt.registerOutParameter(3, Types.VARCHAR);

  cstmt.setObject(1, BigDecimal.valueOf(1), Types.DECIMAL);
  cstmt.setObject(2, "ABC", Types.VARCHAR);
  cstmt.execute();

  Same procedure call with JVx:

  OutParam ouTextParam = new OutParam(InOutParam.SQLTYPE_VARCHAR);
  InOutParam ioNumberParam = new InOutParam(InOutParam.SQLTYPE_DECIMAL,
                                            BigDecimal.valueOf(1));
  dba.executeProcedure("execProcedure", ioNumberParam, "ABC", ouTextParam);

  The Oracle procedure:

  CREATE OR REPLACE PROCEDURE execProcedure(pNumber IN OUT NUMBER,
                                            pInText IN VARCHAR2,
                                            pOutText OUT VARCHAR2) IS
    nr NUMBER := pNumber;
  BEGIN
    pOutText := 'Out: '|| pOutText ||' In: '|| pInText;

    pNumber := pNumber + pNumber;
  END execProcedure;

• Custom UI factories

  It's now fully supportet that you create your own UI factories or extend existing factories. A JVx application will use your custom factory. This allows replacement of single standard components with your own components or simply integrate new components in your application.

• Oracle Forms integration

  The whole framework was successfully integrated in Oracle Forms applications. A JVx application or a single screen interacts with Forms like standard Forms screens. It's now possible to use modern UI elements in your Forms application without changing or migrating the whole application. We use both technologies and that boosts development time.

• Full NTLMv2 authentication support

  We had support for NTLMv1 in JVx 1.0 and earlier, but with modern Windows OS' you had to set a registry key to force NTLMv1 because the OS' used NTLMv2. We now support modern Windows versions (Vista, Win7, Win8) out-of-the-box.

• JVx is ready for Embedded devices

  We made some experiments with embedded Hardware like RaspberryPi or Beagleboard. We always used JVx for our applications and JVx 1.1 works without problems. If you're interested in our experiments, check our Videos on YouTube.

• Pimped standard Save file dialog to ask for override existing files
• Prepared JVx for JVx.mobile

The complete changelog is available here.

If you have remote controlled, electronical, window shutters, continue reading. If you don't have them, this article might not be interesting for you?
I have such window shutters and a lot of windows. I don't own a control center that allows me to automatically open and close my shutters every morning and evening. I do it every day manually. Sometimes sooner and sometimes later - depends on the day of the week.

Why I don't own a control center?
Such control centers are expensive and do not offer expected features. Some of my features are controlling via SMS, controlling via Internet, move shutters to a specific position (not only up and down).

I didn't really search for a solution of my "problem" because it was not a problem, it was an everyday task and it was habitual. Since I own a RaspberryPi, I tried to find useful solutions, not only Hello worlds. That's the reason why I tried to control my window shutters via Raspberry Pi.

The first big problem was, that it was not possible to find a sender for my shutters. The frequency was 433,42 MHz, but there were no ready-to-use solutions. It was not my intention to solder my own sender and record and decrypt the signal. So, I decided for the easy way: Connect an existing remote control with my Pi. It makes no difference for the remote control, if you press buttons manually or a Pi does the job.

It was not a big problem to find some cheap 3V relais. The soldering was fun and not rocket science. Here is the result:

Remote control

My remote control got a new brain. It works with and without connected Pi. I didn't damage it
The only thing I had to do, was programming every receiver with one (or more) channel of my remote control. Because one button should control all window shutters. But that was a task of 5 minutes.

The hardware was ready and the next step was a fancy client application for controlling my Pi. The plan was a simple application that shows one of my windows. The shutter should move like the original. The application should connect to my Pi via my LAN.
I used JVx and vert.x on server-side for the GPIO control, wrote a nice Deskotp application with JavaFX, some transitions and JVx for the communication to my server. And here is the result:

The application moves the shutter like its big brother. One feature is transparency on mouse over, because you wanna know the position if you stop it.

And if you are interested how software and hardware acts together:

The project was really cool because the source code for the whole thing was minimal, the costs were not comparable to a control center from the manufacturer and I have all features I ever wanted.

Interested in the source code?

Server-side, JVx style:

And my client simply calls: