Recently I had to do a thorough review of one of our very old products. A lot of the code was written over 10 years ago. Initially built with Apache Ant, it was one of our very first products to use Apache Maven as its build tool.
The most striking feature of the exercise was the comfort I felt with the project structure. This was a “multi-module Maven web application”. What it meant is: I know where most of the files are going to be. If the application is using Hibernate, the “hbm” files are probably in “src/main/resources” and probably the same with Spring configuration or any other configuration files. The JSP pages will be somewhere in the src/main/webapp folder. The pom.xml will tell me every dependency this application has; where to find the code for previous releases etc. and all this, without even having to open the IDE or even knowing what the application is about.
There is no need to “Migrate the project to the newer version of the IDE”.
In fact, there is no need to know which IDE was used to build this application or which IDE you want to use right now. You can do with just a command line terminal.
Build tools have existed from the first day we started to write programs but they have always been unopinionated. They would, well, just build! The organization of the project was up to the individual, corporate standards, best practices or the IDEs used. In the Java world, this role was performed by Apache Ant, a direct descendant of the venerable ‘make’ tool but without its idiosyncrasies. It is an imperative build tool that is driven by ‘targets’ defined in an xml file, but still with no opinion on how a Java project should be structured. Ant is undoubtedly powerful and still popular. As of the writing of this article, the latest release of Ant came out just last month. Yet, with all its capabilities, Ant is just another build tool like ‘make’.
Declarative and with an opinion about everything, Apache Maven is as “un-make” as it could be. It defined a standard directory layout – standard locations for most common artifacts used to build Java applications. It defined ‘co-ordinates’ to uniquely name components built using Maven. It defined dependency management using the ‘co-ordinates’, it defined repositories where the outputs can be stored and retrieved seamlessly and it defined a standard build lifecycle. Fortunately, Maven picked up the best practices from the hundreds of open source Apache Java projects and for most purposes the ‘opinions’ were just right. The net effect of all this standardization is that a developer from Coimbatore working on a web application using Eclipse can move to Cincinnati and be at home with a console application built using IntelliJ without skipping a beat. It also means that you can look at a 10-year-old code and still feel comfortable with it. Having a standard project layout is very helpful for individuals but the real kicker is the productivity boost the entire Java community gets because of the Maven coordinates – the ability for every organization to unambiguously share/provide their artifacts to the community.
Maven gets a lot of criticism from the community; some of which, is justified. To truly appreciate what Maven brings to the table, you need to be a polyglot developer. Consider reviewing a 10 year old node or C/C++ or C# program(s)!!! Or consider the tooling coming in new languages (say dotnet core), there is a hint of Maven everywhere. In today’s world, any organization that is doing Java development and does not use Maven, is doing a great injustice to itself and the community as a whole – they are missing out on what truly is Java’s secret super power.
The author, Anish Thomas is Technical Director & Chief Architect at Evolvus Solutions. He has over two decades of experience in setting up engineering processes and evaluating technology along with multi-industry product development experience spanning ERP, Healthcare and Banking products. At Evolvus, he is the final word for engineering management, product design, software architecture and tech coaching.