Project Naming on IntelliJ: groupId, artifactId, version

다음 내용은 Apache Maven Project의 "Guide to naming conventions on groupId, artifactId, and version"을 발췌한 내용이다.

Link: https://maven.apache.org/guides/mini/guide-naming-conventions.html

사실 내가 Intellij를 사용해서 제목을 위와 같이 지었을뿐, Intellij와 무관한 Maven Project Naming rule이다.

groupId

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. eg. org.apache.maven, org.apache.commons

"groupId"는 모든 프로젝트들 사이에서 당신의 프로젝트를 유일하게 식별할 것이다. 따라서 우리는 naming schema를 강제할 필요가 있다. 이것은 package name 규칙을 따라야 한다. 그것은 최소한 당신이 컨트롤하는 domain name이 되어야 하고, 당신은 원하는 만큼의 서브그룹들을 생성할 수 있다는 의미이다. 예를 들어 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

groupId를 정하는 좋은 방법은 프로젝트 구조를 이용하는 것이다. 즉, 만약 현재 프로젝트가 다수의 모듈로 구성되었다면, 그것은 상위 groupId에 새로운 identifier를 이어 붙이는 것이다. 예를 들어 org.apache.maven의 하위 프로젝트 이름은 org.apache.maven.plugins 또는 org.apache.maven.reporting 과 같이 정한다.

 

내가 컨트롤할 수 있는 domain을 활용하여 groupId를 지정해야 한다. 내가 회사에 속한 경우, 회사 domain을 역순으로 표기하는 방법을 사용한다. 사내에서 유일한 Namiming만을 고려하면 모든 프로젝트 중에 유일한 프로젝트 이름을 선정할 수 있다. 또한 하위 프로젝트는 상위 프로젝트의 groupId에 새로운 식별자를 연결하여 구조화하자.

 

artifactId

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

artifactId는 버전을 제외한 jar 파일의 이름이다. 당신이 만약 이것을 생성했다면, 특수문자 없이 소문자로 당신이 원하는 이름으로 선택할 수 있다. 또한 만약 Third party jar인 경우 그것이 배포된 이름을 사용해야 한다.

 

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

만약 당신이 이것을 배포한다면 당신은 점으로 구분되는 일반적인 버전명을 고를 수 있다. SNAPSHOT을 빌드와 관련된 날짜를 사용하지 마세요. 만약 그것이 Third party artifact라면 (이상해보일 지라도)당신은 그들의 버전 넘버를 이어받아 사용하도록 한다.