| ------ |
| Guide to Naming Conventions |
| ------ |
| Carlos Sanchez |
| ------ |
| 1 November 2005 |
| ------ |
| |
| Guide to naming conventions on groupId, artifactId and version |
| |
| [] |
| |
| * <<groupId>> will identify your project uniquely across all projects, |
| so we need to enforce a naming schema. It has to follow the package name rules, what |
| means that has to be at least as a domain name you control, and you can create as many subgroups |
| as you want. Look at {{{http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7} |
| More information about package names}}. |
| |
| eg. <<<org.apache.maven>>>, <<<org.apache.commons>>> |
| |
| A good way to determine the granularity of the <<<groupId>>> is to use the project structure. That is, if |
| the current project is a multiple module project, it should append a new identifier to the parent's |
| <<<groupId>>>. |
| |
| eg. <<<org.apache.maven>>>, <<<org.apache.maven.plugins>>>, <<<org.apache.maven.reporting>>> |
| |
| * <<artifactId>> is the name of the jar without version. If you created it then you can choose |
| whatever name you want with lowercase letters and no strange symbols. If it's a third party jar |
| you have to take the name of the jar as it's distributed. |
| |
| eg. <<<maven>>>, <<<commons-math>>> |
| |
| * <<version>> if you distribute it then you can choose any typical version with numbers and dots |
| (1.0, 1.1, 1.0.1, ...). |
| Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third |
| party artifact, you have to use their version number whatever it is, and as strange as it can look. |
| |
| eg. <<<2.0>>>, <<<2.0.1>>>, <<<1.3.1>>> |
