Maven Coordinates Naming Conventions: Best Practices for groupId and artifactId

Nov 20, 2025 · Programming · 7 views · 7.8

Keywords: Maven | groupId | artifactId | naming conventions | Java package

Abstract: This article delves into the naming conventions for Maven coordinates, specifically groupId and artifactId, based on official guidelines and community best practices. By analyzing the relationship between Java package naming rules and Maven project structure, it explains how to choose appropriate groupId and artifactId. Includes concrete examples and code snippets to help developers understand the logic behind naming conventions, avoid common pitfalls, and ensure project identifiability and consistency in the Maven ecosystem.

Fundamentals of Maven Coordinates Naming

In Maven projects, coordinates are core elements that uniquely identify artifacts (e.g., JAR files), consisting of groupId, artifactId, and version. Adhering to naming conventions is crucial for project maintainability and discoverability in Maven repositories. This article details the principles for naming groupId and artifactId, drawing from official documentation and community consensus.

Naming Conventions for groupId

The groupId uniquely identifies a project group globally and typically follows Java package naming rules. This requires a reverse-domain-name format, starting with a domain you control. For example, if the company domain is mycompany.com, the groupId should begin with com.mycompany. This convention ensures uniqueness and prevents naming conflicts.

In practice, groupId can align with the Java package name, a common approach. For instance, if the Java package is com.mycompany.teatimer, the groupId can be set to com.mycompany.teatimer. This promotes clarity in project structure. For multi-module projects, append sub-identifiers to the parent groupId, such as org.apache.maven.plugins.

Naming Conventions for artifactId

The artifactId is the name of the artifact, usually corresponding to the base name of the JAR file. Conventions recommend using lowercase letters, digits, and hyphens, avoiding special symbols. Hyphens are often used to separate words for better readability. For example, for a project named "tea timer", the artifactId can be tea-timer instead of teatimer.

Although in full coordinates like com.mycompany.teatimer.tea-timer, hyphens might seem awkward, this is a widespread practice in the Maven community. It ensures artifact names are filesystem-friendly and easily recognizable by other developers. Examples include commons-math.

Practical Application Examples

Consider a project with a Java package name com.mycompany.awesomeinhouseframework. Following the conventions, the groupId can be com.mycompany.awesomeinhouseframework, and the artifactId can be awesome-inhouse-framework. This makes the artifact path clear in Maven repositories.

Here is a simple Maven POM file example illustrating how to define these coordinates:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.awesomeinhouseframework</groupId>
  <artifactId>awesome-inhouse-framework</artifactId>
  <version>1.0.0</version>
</project>

In this code, groupId and artifactId adhere to naming conventions, ensuring project standardization.

Advantages and Considerations of Naming Conventions

Following Maven naming conventions offers multiple benefits: enhanced project discoverability, reduced dependency conflicts, and improved team collaboration. However, developers should note that groupId must be based on a controlled domain; avoid single words like myproject, as they may not be approved for the Maven Central Repository.

Additionally, version naming should follow Semantic Versioning, e.g., using formats like 1.0.0, and avoid date labels in stable versions. For snapshot versions (e.g., 1.0.1-SNAPSHOT), Maven handles them specially, facilitating testing and iteration.

Conclusion

Naming conventions for Maven coordinates are key to successful integration into the Maven ecosystem. By using reverse-domain groupId and hyphen-separated artifactId, developers can ensure project uniqueness and readability. The examples and explanations provided in this article aim to help both beginners and experienced developers avoid common pitfalls and enhance project management efficiency.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.