Welcome!

Eclipse Authors: Pat Romanski, Elizabeth White, Liz McMillan, David H Deans, JP Morgenthal

Related Topics: Java IoT

Java IoT: Article

An Introduction to Maven - Part I

A promising application development lifecycle management framework

Maven is a promising application development lifecycle management framework coming from Apache's armory of open source tools. Maven was originally developed as a framework to manage and mitigate the complexities of building the Jakarta Turbine project and soon became a core entity of the Apache Software Foundation project.

Without a uniform application development lifecycle management framework, different development teams would create their own build frameworks with varying flavors and complexity and this tendency would only proliferate as more and more new projects get developed. The creation of different build approaches for different projects would lead to build system disparity lacking reuse of build logic that would impede developers in moving easily between the projects because every time a developer starts working on a different project, the developer would spend too much time understanding the prevalent build system, its configuration, and usage instead of focusing on the core components.

This type of perplexity was particularly felt in the open source community. There was a definite need for a standardized project development lifecycle management system. The advent of Maven as part of the Jakarta Turbine project was the perfect remedy for the old malady.

As the name suggests, Maven is a connoisseur of build process. It encapsulates years of project development lifecycle management knowledge and tremendously simplifies the build process by extensively reusing build logic and eliminating most of the grunt work typical of the usual application development process. Ever since, Maven has been extensively used in the open source community for building projects and in the process was enhanced and extended to bring it to its current mature state. Maven, currently at version 2, has become the de facto build system in many open source initiatives and is being adopted by many software development organizations.

Development teams usually would have a plethora of challenges and concerns during typical application project development. The following are a few such examples:

  • What should the project directory structure be?
  • How should source, test source, libraries, configuration, documentation, and report directories be laid out?
  • Where should the dependent library Jars be downloaded from?
  • What versions of library Jars should be used for the project?
  • What about the other Jars that the project library Jars depend on internally? Where should such Jars be downloaded from? What versions of such Jars should be used? Is there an easy way to know the compatible versions?
  • What is the best way to resolve dependent library Jar version conflicts?
  • Where should the library Jars be located?
  • How should the project keep up with the latest versions of dependent Jar files?
  • How should the compile time, runtime, and testing time classpath libraries be separated?
  • How should compile time, runtime, and testing time resources be separated?
  • Is there an easy way to execute all test cases during the build process and immediately evaluate percentage test coverage?
  • Is there an easy way to test code quality during the build process?
  • Is there a way to integrate code profiling during the build process?
  • Is there a way to run integration tests during the build process? How can continuous integration be achieved by developing custom build scripts?
  • How should the build scripts be designed for different project building tasks?
  • Where should build scripts be located in the overall project directory structure?
  • Should there be a dedicated resource to maintain the build scripts while the project is being developed?
  • How can consistent company-wide Jar libraries be maintained?
  • Should new team members learn the custom build process?
  • Should each project have its own inconsistent and typically non-standard build process?
Maven thoroughly addresses such concerns by providing a common project build model that can be reused by all software projects. Maven abstracts the project structure and contents by following a set of guiding principles such as "convention over configuration," "declarative execution of development lifecycle process," "reuse of build logic across projects," and "logical organization of project dependencies."

The key benefit of this approach is that developers will follow one consistent build lifecycle management process without having to reinvent such processes time and again. Ultimately this will make developers to become more productive, agile, disciplined, and focused on the work at hand rather than spending time and effort doing grunt work understanding, developing, and configuring yet another non-standard build system.

Standard Conventions Used by Maven
Maven goes by the notion of "convention over configuration." Some of the common concerns when building a project are project directory structure, directory naming conventions, and the build output. For example, the directory structure of a Web application project will be slightly different from that of an EJB application project. Similarly the output of a Web application project is typically a WAR file while that of an EJB application is a JAR file. However, for a specific project type, the typical requirements in terms of directory layout and naming conventions are almost the same. Without a unified framework such as Maven, developers would typically spend time configuring such nitty-gritty details as setting up directories for source, resources, test case source, testing time resources, classes, and project dependencies. Moreover, developers will have to spend a good chunk of time creating build scripts such as ANT scripts to execute build tasks according to the project layout. This entire endeavor ends up being chaotic and in a large-scale project it can lead to a maintenance nightmare demanding dedicated resources just to focus on such build aspects.

Maven inculcates three main conventions to address common concerns:

1.  Projects of the same project type will have one common standard project directory structure: At project creation, Maven uses a standard project directory layout for source files, resources, test case source files, test resources, configuration files, output files, reports, and documentation. In almost all cases, this standard project directory layout is sufficient to carry out development tasks. However, a custom directory structure can also be configured by overriding Maven's defaults. This override is not generally recommended unless there's a compelling reason and will deviate from Maven's best practice propositions.

2.  Every project results in one primary artifact of specific type: Every project in Maven will result in one primary output file known as an artifact. For example, a Maven project containing a mathematical utility API will yield a JAR file containing compiled utility classes. The output JAR file is the resulting artifact of that project. Some other common artifact types are WAR, EAR, and RAR. Each artifact in Maven is uniquely designated by three Maven coordinates; artifact Id is the actual name of the artifact, group Id is the name of the group the artifact belongs to and the artifact version. This convention helps tremendously while resolving dependencies because every dependency in Maven is an artifact and so every dependency can be uniquely identified. This convention enables developers to think in terms of modularization at the code base level so that each project module yields one specific artifact specializing in one area of concern. This type of modularization encourages maximum reusability with different projects can now depend on only one functionally specialized and distinct artifact without having to include multiple disparate artifacts that may contain pieces of the required functionality.

3.  Use of standard naming conventions: Maven uses standard names for project directories and output files. For example, Maven creates a standard 'projectDirectory/src/main/java' directory for all Java source files and 'projectDirectory/src/test/java' directory for all Java test case source files. Similarly, while creating a project artifact, Maven follows a standard naming convention such as 'artifactName-version.' An artifact version is typically represented in a standard format of 'MMM.mmm.bbb-qqqqqqq-nn' where 'MMM' is the major version number, 'mmm' is the minor version number, 'bbb' is the bug fix number,' 'qqqqqqq' is an optional qualifier, and 'nn' is an optional build number. Such naming conventions offer immediate clarity and in the case of artifacts, enable cohesive and consistent organization of dependencies using their respective artifact coordinates.


More Stories By Murali Kashaboina

Murali Kashaboina leads Enterprise Architecture at United Airlines, Inc. He has 15+ years of enterprise software development experience utilizing a broad range of technologies, including JEE, CORBA, Tuxedo, and Web services. Murali previously published articles in WLDJ and SilverStream Developer Center. He has master’s degree in mechanical engineering from the University of Dayton, Ohio.

More Stories By Geeth Narayanan

Geeth Narayanan is a senior architect at Ecommerce Technology, United Airlines, Inc. He has 10 years of experience in the IT industry, specializing in solutions using Java EE technologies. Geeth has master's degree in electrical engineering from the University of Toledo, Ohio.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
While the focus and objectives of IoT initiatives are many and diverse, they all share a few common attributes, and one of those is the network. Commonly, that network includes the Internet, over which there isn't any real control for performance and availability. Or is there? The current state of the art for Big Data analytics, as applied to network telemetry, offers new opportunities for improving and assuring operational integrity. In his session at @ThingsExpo, Jim Frey, Vice President of S...
Rodrigo Coutinho is part of OutSystems' founders' team and currently the Head of Product Design. He provides a cross-functional role where he supports Product Management in defining the positioning and direction of the Agile Platform, while at the same time promoting model-based development and new techniques to deliver applications in the cloud.
@CloudEXPO and @ExpoDX, two of the most influential technology events in the world, have hosted hundreds of sponsors and exhibitors since our launch 10 years ago. @CloudEXPO and @ExpoDX New York and Silicon Valley provide a full year of face-to-face marketing opportunities for your company. Each sponsorship and exhibit package comes with pre and post-show marketing programs. By sponsoring and exhibiting in New York and Silicon Valley, you reach a full complement of decision makers and buyers in ...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
As data explodes in quantity, importance and from new sources, the need for managing and protecting data residing across physical, virtual, and cloud environments grow with it. Managing data includes protecting it, indexing and classifying it for true, long-term management, compliance and E-Discovery. Commvault can ensure this with a single pane of glass solution – whether in a private cloud, a Service Provider delivered public cloud or a hybrid cloud environment – across the heterogeneous enter...
LogRocket helps product teams develop better experiences for users by recording videos of user sessions with logs and network data. It identifies UX problems and reveals the root cause of every bug. LogRocket presents impactful errors on a website, and how to reproduce it. With LogRocket, users can replay problems.
Data Theorem is a leading provider of modern application security. Its core mission is to analyze and secure any modern application anytime, anywhere. The Data Theorem Analyzer Engine continuously scans APIs and mobile applications in search of security flaws and data privacy gaps. Data Theorem products help organizations build safer applications that maximize data security and brand protection. The company has detected more than 300 million application eavesdropping incidents and currently secu...
Rafay enables developers to automate the distribution, operations, cross-region scaling and lifecycle management of containerized microservices across public and private clouds, and service provider networks. Rafay's platform is built around foundational elements that together deliver an optimal abstraction layer across disparate infrastructure, making it easy for developers to scale and operate applications across any number of locations or regions. Consumed as a service, Rafay's platform elimi...
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound e...
In today's enterprise, digital transformation represents organizational change even more so than technology change, as customer preferences and behavior drive end-to-end transformation across lines of business as well as IT. To capitalize on the ubiquitous disruption driving this transformation, companies must be able to innovate at an increasingly rapid pace.