Sign In Start Free Trial

Book Overview & Buying
Table Of Contents
Feedback & Rating

Maven Essentials

By : Russell E Gold, Siriwardena

3.9 (8)

Maven Essentials

3.9 (8)

By: Russell E Gold, Siriwardena

Overview of this book

Maven is the #1 build tool used by developers and it has been around for more than a decade. Maven stands out among other build tools due to its extremely extensible architecture, which is built on of the concept of convention over configuration. It’s widely used by many open source Java projects under Apache Software Foundation, Sourceforge, Google Code, and more. Maven Essentials is a fast-paced guide to show you the key concepts in Maven and build automation. We get started by introducing you to Maven and exploring its core concepts and architecture. Next, you will learn about and write a Project Object Model (POM) while creating your own Maven project. You will also find out how to create custom archetypes and plugins to establish the most common goals in build automation. After this, you’ll get to know how to design the build to prevent any maintenance nightmares, with proper dependency management. We then explore Maven build lifecycles and Maven assemblies. Finally, you will discover how to apply the best practices when designing a build system to improve developer productivity.

Preface

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

1. Apache Maven Quick Start

1. Apache Maven Quick Start

Installing Apache Maven

Configuring the heap size

Hello Maven!

Convention over configuration

Maven repositories

IDE integration

Troubleshooting

Summary

2. Understanding the Project Object Model (POM)

2. Understanding the Project Object Model (POM)

Project Object Model (POM)

POM hierarchy

Super POM

POM extending and overriding

Maven coordinates

The parent POM

Managing POM dependencies

Summary

3. Maven Archetypes

3. Maven Archetypes

Archetype quickstart

Batch mode

Archetype catalogues

The archetype plugin goals

Java EE web applications with the archetype plugin

Android mobile applications with the archetype plugin

EJB archives with the archetype plugin

JIRA plugins with the archetype plugin

Spring MVC applications with the archetype plugin

Summary

4. Maven Plugins

4. Maven Plugins

Common Maven plugins

Plugin discovery and execution

Summary

5. Build Lifecycles

5. Build Lifecycles

Standard lifecycles in Maven

Lifecycle bindings

Lifecycle extensions

Summary

6. Maven Assemblies

6. Maven Assemblies

The assembly plugin

The assembly descriptor

Artifact/resource filtering

Assembly help

A runnable standalone Maven project

Summary

7. Best Practices

7. Best Practices

Dependency management

Defining a parent module

POM properties

Avoiding repetitive groupIds and versions, and inheriting from the parent POM

Following naming conventions

Think twice before you write your own plugin. You may not need it!

The Maven release plugin

The Maven enforcer plugin

Avoiding the use of unversioned plugins

Descriptive parent POM files

Documentation is your friend

Avoid overriding the default directory structure

Using SNAPSHOT versioning during the development

Get rid of unused dependencies

Avoiding keeping credentials in application POM files

Avoiding using deprecated references

Avoiding repetition – use archetypes

Avoiding using maven.test.skip

Summary

Index

Index

Customer Reviews

3.9 (8)

5 star

37.5%

4 star

25%

3 star

25%

2 star

12.5%

1 star

0

Following naming conventions

When defining coordinates for your Maven project, you must always follow the naming conventions.

The value of the groupId element should follow the same naming convention you use in Java package names. It has to be a domain name (the reverse of the domain name) that you own—or at least that your project is developed under.

The following list covers some of the groupId naming conventions:

The name of the groupId element has to be in lower case.
Use the reverse of a domain name that can be used to uniquely identify your project. This will also help to avoid collisions between artifacts produced by different projects.
Avoid using digits or special characters (for example, org.wso2.carbon.identity-core).
Do not try to group two words into a single word by camel casing (for example, org.wso2.carbon.identityCore).
Ensure that all the subprojects developed under different teams in the same company finally inherit from the same groupId and extend the name of the parent groupId...

Search

Your notes and bookmarks