Tag Archives: javascript

Oh My js! Server side javascript for java developers?

Javascript tooling set was enriched a lot these last years: npm, bower, gulp, grunt, … but most of them work on nodejs and need a certain amount of knowledge before being able to get anything from it.

For a Java developer it can be complicated and tempting to do a plain JSP instead of embrassing javascript.

Making javascript development easy can only be done in the case of a framework with a lot of defaults cause by nature you need to develop in an exploded fashion (by module) fr the maintenance and aggregate them at the end for performances reasons (HTTP 2.x will maybe make it smoother but will likely not replace it completely).

If your project is before all a frontend project you need to go on js side but if your project is simple and more centered on the data or the server side we can probably find a compromise.

This was the origin of “Oh My js!” which is a small library I created to integrate the pipeline I often use for frontend development with Maven and the Java stack I use (TomEE if you doubt of it ;)).

First of all what needs do I want to cover and which ones I’ll ignore:

  • dependency management: ignored. I only want to handle runtime js dependencies and they are not that numerous in general so it can be done manually or worse case using webjars and a small groovy script for the optimization – will not be part of this post but can be another one if needed
  • build: yes and no. There are multiple parts of a build in javascript: the “big final aggregation” which aims to put all resources we can in a single file to make client loading faster and (optional) each module transpilation/rendering/compilation/… This is this last part we will target
  • test: java has a good tooling to do it but see next note for a more nuanced answer
  • packaging: not sure javascript has a real packaging model yet but java has so all is fine and secured
  • deployment: I build a war so maven/gradle are perfect

Of course I listed far more that what this post will cover but it was to show that the “blocking” part for a java developer is finally small enough to get some work to fill the gap.

Side note: frontend-maven-plugin is a great tool bringing to maven nodejs tooling (npm, bower, gulp, karma…). This however still needs to know these tools and just provide a “main-build” friendly solution so the initial cost can be important but it can worth it if you will need a lot of javascript.

Continue reading

Mix TomEE embedded and Angular 2 with Maven

Since months a typical web application is a JAX-RS for the server-side and a javascript on the client-side.

This powerful architecture can sometimes reveal some challenges in the build pipeline.

However today it is not that hard to mix both frontend and backend build tools to get a single build pipeline easily integrable in a continuous integration solution.

To illustrate that we’ll digg into how to create an Angular 2 application packaged with Maven.

Continue reading

Simple JAX-RS resource to match Can.JS defaults

Can.JS is a nice client side (javascript) library providing a MVC solution out of the box. The model is often backed by some JSON server and in Java(EE) case by JAX-RS.

Can.JS has a shortcut for CRUD models called ‘resource’ based on a default mapping. Let see how to implement it on a Java server side easily.

Continue reading

JavaEE + CanJS: uncap your dev!

Writing a website today often looks like writing a REST server to provide data to a rich client side application.

JavaEE is a killing stack to quickly deploy a JAX-RS application and everybody is using angularjs for the client side.

However there are several alternatives that worth a look. One of them I particularly like is CanJS. In my opinion, it is lighter and more classical than angular, by letting you integrate “default” javascript libraries and not the “ng-” version which doesn’t always work as good as the original. Of course it needs a bit more work but once setup it is really smooth.

Let’s get started with this modern stack!

Continue reading