In Support Of Maven

In the last few days there has been an article completely bashing Maven on hacker news. I found this a little aggravating. Much of the article spent time complaining about how the files are structured, and how much effort it takes to maintain a Maven file. Also, the article complained about the plug-in structure.

To some extent I can agree with the original author. The plug-in system makes Maven a little difficult to learn and get completely right. On the other hand, the plug-in system makes it easy to deliver a single meta-build system that can easily adapt to what you need it to do. Building a Java web app? It has a plug-in to build and package it for you.

My main beef with the article is that it completely ignores why we got Maven in the first place. It builds, packages, and manages your dependencies better than ANT does. Before, you had to manually acquire, and grab your dependencies. If you had ANT or make, then you had to include the declarations for the dependencies in the build file, and put the dependency in your project. This is a pain for those that are using source control, and for setting up new developer machines. However, with Maven, just declare the dependency and the scope in the build file and you’re done. If you’re using an IDE it’ll bring in the references and may be able to pull the Javadoc if it’s available. Additionally, any new upgrades to the dependencies could be added just by changing the version number. Imagine doing that without a Maven like build system. Maven can even go the extra mile and create a redistributable package [this is a little tricky, but you can do it], deploy your new package to a repository, check in your code for you, or even deploy it to a webserver. For example, if you have a web service and don’t have Tomcat7 downloaded, run it with an embedded instance with mvn tomcat7:run . You’re done, Maven grabs Tomcat7, its dependences and tries to deploy your webapp to the new instance of Tomcat7. No installation of the server required.

In closing, Maven is a build tool. Unless you’re making project structure changes you shouldn’t be messing about with the way it builds things.

Links I’ve Found Interesting in the Last Week/Technical Things I’ve found Interesting (6 January 2013)

  • Getting the “Application Server Libraries not found” error with IntelliJ when you try to add a local Tomcat server? If you’re using Gentoo it’s a matter of file locations. Install the tomcat-api package, and make a symbolic link from the API within the Common and Shared Tomcat directories. Source.
  • Tomcat 7 has changed around how resources can be accessed. You can no longer use “getResourceAsStream” to get files placed in the Web-inf/Classes folder. Instead, you should attempt to get the resource through the context of the local thread. An example: Thread.currentThread().getContextClassLoader().getResourceAsStream(). This is useful for applications that use JasperReports [location of the JRXML file], and that are web applications. Source.
  •  If you are trying to stand up a web server, and don’t want to allow it to accept public connections? Set the accepted connections on tomcat to only listen on the local address. For tomcat see this. For NGinx see and set it only set listen to[port].
  • Converting a GUI Netbeans project into a Maven based project? Most of the needed libraries will be covered by the default Maven repositories. However the swing-layout dependency is a special case. To use include the Netbeans repository reference, and include the swing-layout-1.0,4 dependency.



  • Ignoring failed tests on a maven build: Add this parameter to your mvn command: -Dmaven.test.skip=true
  • Sort directories and files with a human readable format: This is like ls –Sh, but it traverses directories.
  • If you have a set of directories to ignore, SVN propset includes an option to recursively ignore specified names/folders. A word of warning propset overwrites any svn:ignore properties.