tfnico's blog

Disclaimer: I'm a Java developer, not a JavaScript developer. This is just what I've picked up the last years plus a little research the last days. It's just a snapshot of my current knowledge and opinions on the day of writing, apt to change over the next weeks/months. We've gone all modern in our web applications, doing MVC on the client side with AngularJS or Ember , building single-page webapps with REST backends. But how are we managing the growing amount of JavaScript in our application? Yeoman 's logo (not necessarily the conclusion of this blog post) You ain't in Kansas anymore So far we've just been doing half-random stuff. We download some version of a library and throw it into our src/main/webapp/js/lib , or we use it from a CDN , which may be down or unreachable when we want to use the application.. Some times the JS is minified, other times it's not. Some times we name the file with version number, other times without. Some ...

I'm dare say I'm a seasoned Hudson user (admin) and proponent. For over five years I've been introducing different kinds of CI at whichever place I worked at. When Hudson entered my radar, this work became a lot easier. I'm also a heavy Maven user, and Nexus did for Maven repositories what Hudson did for CI. The Plot Over recent weeks, the community around Hudson has been shaken by a fork: The main developers ( Koshuke and crew) have renamed Hudson to Jenkins , while Oracle have kept on developing Hudson in partnership with Sonatype . Here's a simple illustration of what happened: These are my pure external speculations about what has happened recently in the forking process, with regards to Sonatype's involvement in particular. So who is running this show? I noticed that Sonatype (usually personified by Jason) have gotten their fingers pretty deeply into the Hudson infrastructure already: Like  this tweet  noted, it appears they are controlling ...

A typical misconception in Maven is that if you want to build a project in a special way, or parameterize it somehow, profiles are the thing for you. My opinion is that.. Profiles are POM smell. While I know they have their uses, I have abused profiles heavily in the past, and seen others do this too. What might start off as a simple little trick to get some desired build eventually leads to: One profile for each testing category (unit, database, web-tests, etc) (Hint: Use a test framework that supports grouping ) One profile for each environment/stage configuration (testing, live, etc) (Hint: Use a tool that supports  stage-aware configuration ) One profile for each artifact assembly (exclude module X when deploying in certain environments) The POM ends up awfully complicated, you get confusion around what kind of artifact is deployed where, and people start hating Maven because they forget -P parameters when they build, and end up rebuilding the whole project to change...

I noticed via @jvanzyl that Kent R. Spillner has been taking apart Maven and some of its features in a recent rant . The twittersphere has shown support for Kent's views - and being the Maven fan I am , I figured I'd take some time to try countering his post a bit (forgive me if this post is a bit unstructured, I'm trying to squeeze it out under some time pressure). "The best build tool is the one you write yourself..." I think this first paragraph contains a lot of absolute statements that happen to be false in a lot of cases. My experience is that a lot of projects or modules are built the same way. It's a bunch of source code, and in the end you end up with a JAR-file. We've got a 25 module web application at work, and I just mavenized the whole thing from Ant. All of the modules exlucding the final web-app module itself were easily built with Maven. Nobody says that every module in the world is built this way, but it sure is a lot. Java code goes in,...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Reason 2: Clean up your JAR-files Huge projects are hard to work with Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project. Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-fi...

Update: Added a summary section at the end of this post. This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Some background Back a couple of months, I got the rewarding task of cleaning up our project's lib folder. You know the one: Crammed with JAR-files of various versions of the various dependencies your project has.. fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar lots and lots of others... ... Yup, good old fizz-libs . It needs to be regularly cleaned up to reduce software rot . Over time, the developers try out new open source libraries and remove the use of old ones, but they seldom take care to clean out the libs-folder, because they don't know if there could be any hidden effects from removing JAR files. Now, at our place we use Eclipse's . classpath file for specifying ea...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven The libs folder We have a libs-module in Subversion. When you check out the source code for our main product, this is one of the modules you get. It contains a hundred-and-some JAR-files. These are the dependencies for the sum of our modules: fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar Downloading all these MB's of JAR files is something you'll have to do no matter which build system you use, so bandwith cost isn't an argument. Subversion also uses binary diffs, so copying or changing a JAR file doesn't increase repository size significantly. The problem arises when you want more than one product. As soon as you want to split your product into two applications (or services), each project needs its own libs-folder : fizz-project \ fizz-core fizz-web fizz-libs \ ...

Update: I'm doing some work to split this blog post into some more fine grained posts in a series. Please, bear with me if these changes are giving you lots of noise in your feed-reader. I used to work as a consultant. My job was to improve our clients' ways of software development. Among the most important things I tried to teach them were: o Good code style and object orientation o Practical use of good open source tools (don't re-invent the wheel) o Automating tests of their software, and continuous integration o Splitting code into modules, dependency-relationships and versions The last point is perhaps the trickiest. It's hard to understand why it's needed in an isolated project, it is hard to explain how it should be done, and most importantly, there is no de-facto way or standard for managing modules, their relationships, versions and scope . This is why me and my consultant buddies embraced Maven many years ago. After years of pushing and evangel...

Update: Fixed camelCase in localRepository tag. It's been a busy week, with JavaZone and some exiting things going on in my project at the same time. I'll get straight to the point and post an exampe app that will solve the problems from the previous post . I started off with a maven archetype create webapp . I added configuration of the Jetty plugin (note that this isn't really necessary to get the rest working, but is handy for testing out the webapp with mvn jetty:run). I put the web-test running in its own profile, so it won't be ran with each mvn install. This is to underline the fact that you probably don't want the web-tests to be run each time you build the app. Web tests take too much time and should be done by your CI system. So, all the details of configuring maven for running Selenese tests are inside the with id "web-test". I've done a few other modifications as well, adding a couple of snapshot repos, and the web tests of cou...