Musings on computers and software as I continue learning and sharing software development knowledge.

Thursday, February 4, 2010

Importance of a Build Utility-3

Wrapping up my discussion about the build utilities, I’ll be covering Maven (http://maven.apache.org) Build Tool in this blog post.

As already discussed, there is a continuous thirst amongst developers to streamline and automate their projects/applications. Going one step further from the build routine leads to the application creation and maintenance, which is automated via Maven?

Maven is a departure from the existing build technologies, which follow a procedural route, and instead, provides a declarative way, using an xml file, to describe the project.

In large scale projects, there is a need for a large number of libraries. This requires external files in the programming context (read as .jar files in classpath). In Maven, we specify these requirements as dependencies. When the application is executed, these dependencies are downloaded from a central location and kept in a directory at the local computer for usage.

Note that in Maven, we use a lot of the Convention Over Configuration stuff, so if you try to ‘bend’ the defaults on your own, it can cause some headache-inducing problems (which means that Maven is not for everything and everyone).

Project Types: Archetype

An Archetype is a template for a project that is created to create a module. This gives us a starting point for our application. We can create such an archetype by :-

mvn archetype:generate

Now we have to answer some values for our project. This is our project type, the group ID, maven ID, Version and the package name of our application.

After the successful execution of this command, the project structure gets created and we have a pom.xml file at the project root. This file is called as POM (Project Object Model) as it contains the information that Maven needs in a declarative and reusable across different projects.

When we build our project, it undergoes a lot of stages or phases (like compiling, unit testing, packaging, deploying, etc) in an ordered manner.

A Small Example

First we will generate our project skeleton using the archetype:generate command

Now, we will get this :

Here, we would set up the project type (in this case, I am setting up 18, for a blank web application).

Then, we will specify the GAV(Group, Artifact and Version) values as well as the default package. After confirmation, our project structure would be created.

Now we can start developing our applications. As soon as we are finished, we can package our application as mvn package command.

Note that we did not created any build scripts ourselves; Maven only asked us about the type of project that we need. So our productivity increases as well as we can adhere to unified build standards.

If you look at the /target folder, then there would be a simple-webapp.war file, which can be deployed in any web server. To run this on tomcat server, for instance, simply issue a mvn tomcat:run

Apart from the build lifecycle discussed here, there are other lifecycles such as cleaning and site generation.It is worth mentioning that, we can make the project an Eclipse project by mvn eclipse:eclipse and so on for other tools.

Now, mainly, we have to take care of the pom.xml file that contains the dependencies, which may arise as and when we expand our application. Rest everything is left to the build utility.

Conclusion

Although it is early for me to comment upon the future of this or any other build tools, but we can expect more automation in future.

Cloud based application servers can provide for automatic classpath management (like IDEs) and maven would not only take on ant as the de-facto tool in java, but also result in numerous spoof offs for other technologies.