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
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...