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 your project is developed under.
The following lists out some of the naming conventions related to groupId
:
groupId
element has to be in lower case.org.wso2.carbon.identity-core
).org.wso2.carbon.identityCore
).groupId
element and extend the name of the parent groupId
element rather than defining their own.Let's go through some examples. You will notice that all the open source projects developed under Apache Software Foundation (ASF) use the same parent groupId
(org.apache
) and define their own groupId
elements, which extend from the parent:
org.apache.axis2
, which inherits from the org.apache
parent groupId
org.apache.synapse
, which inherits from the org.apache
parent groupId
org.apache.servicemix
, which inherits from the org.apache
parent groupId
org.wso2.carbon
Apart from the groupId
element, you should also follow the naming conventions while defining artifactIds
.
The following lists out some of the naming conventions related to artifactId:
artifactId
has to be in lower case.groupId
inside the artifactId
element. If you find a need to start your artifactId
with the value of groupId
element and add something to the end, then you need to revisit the structure of your project. You might need to add more module groups.#
, $
, &
, %
, and so on).identityCore
).Following naming conventions for version
is also equally important. The version of a given Maven artifact can be divided into four categories:
<Major version>.<Minor version>.<Incremental version>-<Build number or the qualifier>
The major version reflects the introduction of a new major feature. A change in the major version of a given artifact can also mean that the new changes are not necessarily backward compatible with the previously released artifact. The minor version reflects an introduction of a new feature to the previously released version, in a backward compatible manner. The incremental version reflects a bug-fixed release of the artifact. The build number can be the revision number from the source code repository.
This versioning convention is not just for Maven artifacts. Apple did a major release of its iOS mobile operating system in September 2014: iOS 8.0.0. Soon after the release, they discovered a critical bug in it that had an impact on cellular network connectivity and TouchID on iPhone. Then, they released iOS 8.0.1 as a patch release to fix the issues.
Let's go through some of the examples:
wso2v5
classifier to make it different from the same artifact produced by Apache Synapse.3.137.163.62