[Maven] Maven groupId, artifactId, version 관리

이번에는 java 빌드 툴인 maven에서 사용하는 groupId, artifactId, version에 대해서 알아보고, Apache에서 제공하는 가이드를 참조하여 올바르게 사용하는 방법에 대해서 포스팅 해보고자 합니다.

groupId, artifactId, version은 강제성은 없다곤 합니다. 다만 제 개인적인 생각으로 개인 프로젝트가 아니라 회사에서 개발하고, 다른 부서나 팀에 제공하는 라이브러리의 경우에는 통일성을 위해서 공인된 기관에서 제공하는 가이드 라인을 따르거나, 회사에서 정한 가이드라인을 따라야 한다고 생각합니다. 그 이유는 회사에서 개발하는 프로젝트들을 개인 프로젝트처럼 진행을 해버리면 통일성이 없어지게 돼서 다른 직원들이 자신이 개발한 프로젝트를 참조하는데 불편함을 느낄 수 있다고 생각하기 때문입니다.

그러므로 회사에서 제공하는 가이드 라인이 있다면 그 가이드 라인을 따르면 될 것 같고, 그게 아니라 java 의 경우 Apache와 같은 곳에서 제공하는 가이드 라인을 따르면 좋을 것 같다고 생각해서 이렇게 포스트를 쓰게 되었습니다.

groupId

Apache Maven Project의 “Guide to naming conventions on groupId, artifactId, and version” 에 있는 groupId에 있는 내용을 인용하자면

• groupId 는 자신의 프로젝트를 모든 프로젝트 사이에서 고유하게 식별하게 해 주는 것이다.
• 그러므로 groupId 는 네이밍 스키마를 적용하도록 한다.
  • groupId package 명명 규칙을 따르도록 한다.
  • 최소한 자신이 컨트롤하는 도메인 네임이어야 한다.
  • 하위 그룹은 얼마든지 추가할 수 있다.
  • ex) org.apache.maven, org.apache.commons
• 프로젝트 구조를 사용하면 잘 구분되는 groupId 를 만들 수 있다.
  • 현재 프로젝트가 다중 모듈 프로젝트라면, 부모 groupId에 현재 프로젝트의 식별자를 추가하는 방식
  • ex) org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

다음은 Apache MAven Project의 “Guide to nameing conveions on groupId, artifactId, and version” 의 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

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

• artifactId 는 버전 정보를 생략한 jar 파일의 이름이다.
  • 이름은 원하는 것으로 아무거나 정해도 상관없다.
  • 단, 소문자로만 작성하도록 한다.
  • 단, 특수문자는 사용하지 않는다.
• 만약 써드 파티 jar 파일이라면, 할당된 이름을 사용해야 한다.
  • ex) maven, commons-math

다음은 Apache MAven Project의 “Guide to nameing conveions on groupId, artifactId, and version” 의 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

version

• 숫자와 점으로 이루어진 일반적인 버전 형태를 사용한다. (1.0, 1.1, 1.0.1 …)
• SNAPSHOT(nightly) 빌드 날짜를 버전으로 사용하지 않도록 한다.
• 써드 파티 아티팩트라면, (좀 이상하게 보일 수 있어도) 그들의 버전 넘버를 이어받아 사용하도록 한다

다음은 Apache MAven Project의 “Guide to nameing conveions on groupId, artifactId, and version” 의 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

마치며

오늘은 Apache에서 제공하는 java 라이브러리의 groupId, artifactId, version 가이드에 대해서 알아보았습니다. 개인 프로젝트를 진행할 때도, 회사에서 개발을 할 때에도 정해진 가이드라인이 없다면 이 가이드라인을 따르는 것이 좋아 보입니다.

본 포스트에 대해서 궁금하시거나 잘못된 내용이 있다면 댓글 달아주시면 감사드리겠습니다!