Npm, Bower, CI and the Network

Ok, I accepted the reality that building single-page applications (SPA) is better done using the tooling options embraced by the JavaScript community, rather than building those apps using purely Gradle or Maven (and respective plugins). The reason being that building a complete web-UI is rather involved and tools like Yeoman, Grunt (Gulp) and Bower provide quite a bit of useful tooling while also having a much larger user-base than the (less complete) options in the Java world.

So life was good. Everything builds. Of course we still need to integrate the app with our backend that provides the REST endpoints. Personally, I prefer it that developers can build the entire stack at once. Also, can we assume that every (Java) developer has Node/Npm intalled?

Luckily, there are some plugins available for Maven and Gradle that provide useful wrappers around Npm and Node:

• Maven Frontend Plugin
• Gradle Grunt Plugin

Thus, with some trial and error you get a fairly portable build (Linux, Mac and Windows) that not only executes the Grunt build but also downloads and installs Node and its dependencies, Grunt, Bower etc.

You think you finally arrived...Things run mostly okay on the continuous integration (CI) server...mmh, wait... "Mostly" is causing some headaches. This is actually an area where I have some frustrations lately. Looks like the Maven Central in the node world is a tad more volatile than Maven central itself.

In the Java world you have 2 layers of protection that ensure that the CI server build process is fairly resilient to internet hick-ups. Heck, it would even build off-line (assuming no library dependency changes were done). First, you have your local repository of course, which in the case of Maven is typically ${user.home}/.m2/

Second, any serious CI environment would also use a dedicated repository manager that serves as a proxy to the outside world, so that for already retrieved dependencies you would not need to hit Maven Central or other 3rd party repositories.

With NPM you all of a sudden realize you are a tad back into the wild west. Not only do you have to consider NPM (Managing tooling dependencies) but Bower (managing JS/CSS dependencies) as well.

NPM actually provides npm-cache - and you see dependencies being cached in your home directory under ~/.npm/. But try to disable your network card...the eternal spinner is yours. It does not even seem to timeout.

You can go offline - kind of - using “npm install --cache-min 9999999 --no-registry” but it does not seem to support things the way Maven/Gradle does: Check the cache first, and only if the dependency does not exist fetch it remotely. See also: https://github.com/npm/npm/issues/2568

Another issue I encountered is with using Protractor for the E2E testing of my AngularJS application. You will usually use webdriver-manager to retrieve the necessary Selenium files/driver for your targeted Browser, e.g. Chrome. Since, I like to make the build as portable as possible, I do a post-install of the web-driver manager, which requires direct network access in package.json:

"scripts": {
  "postinstall": "node_modules/protractor/bin/webdriver-manager update"
}

Bower unfortunately, does its own caching approach which is configured in .bowerrc, e.g.:

"storage": {
"packages": ".bower_cache"
}

So what about using dedicated repository managers as proxy for NPM and Bower?

Artifactory provides support for NPM but not Bower. There is a feature request to support Bower in Artifactory, though. Nexus also has support for NPM. For Bower an open ticket exists.

Maybe people should start rallying behind web-jars more broadly ;-(

Maven and Cloud Foundry - The plugin is here!

It has been an amazing time so far for me working at SpringSource for the past couple of months and today I have finally published my first blog post for the official SpringSource blog. The blog post also marks the Milestone 1 (M1) release of the Cloud Foundry Maven Plugin which will make it much easier for Maven users to deploy their applications to Cloud Foundry.

Thus, checkout the blog post, use the plugin and follow the project over at GitHub. Please provide plenty of feedback - it is highly appreciated!

m2eclipse - Finally there

Yep, I did it - I gave m2eclipse another try, after reading an interview with Jason van Zyl on InfoQ several weeks ago. In it Jason stated that Sonatype is commiteing 8 full-time employees working on the m2eclipse plugin now. As it turns out, I am impressed. For me m2eclipse is finally there where I need it to be. In the past I looked at it several times but it never fit my needs back then. For my jRecruiter project, I am using a slightly modified Appfuse-based Maven pom. As in Appfuse, my project uses Maven profiles to target various different databases such as Postgres and MySql.

For my project, depending on the chosen profile, Maven will filter a file called jdbc.properties and replaces several properties with database specific values during the processing of resources (mvn process-resources).

Here are some properties that are being filtered:

jdbc.driverClassName=${jdbc.driverClassName}
jdbc.url=${jdbc.url}
jdbc.username=${jdbc.username}
jdbc.password=${jdbc.password}
hibernate.dialect=${hibernate.dialect}

In the olden pre-m2Eclipse days, I created my Eclipse project through Maven from the command line using e.g. mvn eclipse:eclipse -P postgresql. Then in Eclipse, I had to manually include a custom jdbc.properties file with build specific properties since Eclipse by itself can't do that type of filtering.

It worked, however, as you can imagine, this can be quite tedious, especially during the early development stage where your project's dependencies may change frequently.

But now m2eclipse is able to handle resources filtering for me from within Eclipse, which is really nice. Additionally, I can manage my dependencies using m2eclipse, and what is even better, I can visualize them as well. This is especially a live-saver when I need to figure out certain transitive dependencies.

This came in quite handy when I converted my project over to logback and SLF4J and needed to figure out all the commons-logging dependencies.

I am using m2eclipse for several weeks now, and I haven't come across any major drawbacks, yet. Granted, I haven't really dug deeply into m2eclipse's features as I primarily use only the subset discussed above, but if you use Eclipse and your project is built using Maven, please take another look at m2eclipse.