Ответ 1

IMO вам не нужно включать org.companyname в artifactId - он просто дублирует информацию, уже присутствующую в groupId, тем самым делая имена артефактов более длинными и менее читаемыми.

Обновление: FYI, просматривая зависимости нашего проекта, я вижу множество подобных примеров, например

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>

<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>

<groupId>net.sf.barcode4j</groupId>
<artifactId>barcode4j-fop-ext-0.20.5-complete</artifactId>

<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>

<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>

<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-libs</artifactId>

<groupId>javax.resource</groupId>
<artifactId>connector-api</artifactId>

<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>

<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>

И тогда есть много, где идентификаторы группы и артефакта являются одинаковым неквалифицированным именем, например:

<groupId>log4j</groupId>
<artifactId>log4j</artifactId>

<groupId>velocity</groupId>
<artifactId>velocity</artifactId>

<groupId>fop</groupId>
<artifactId>fop</artifactId>

<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>

Но я не видел никаких идентификаторов группы и идентичного идентификатора артефакта (например, для Log4J будет org.apache.log4j:org.apache.log4j).

Ответ 2

Использование неквалифицированного имени для groupId, соответствующего артефакту (например, log4j), является старой устаревшей практикой, которая не рекомендуется: это плохо на уровне файловой системы он генерирует "беспорядок репозитория", он затрудняет поиск артефактов при просмотре репозитория (даже если большинство людей используют поисковую систему в наши дни).

Рекомендация состоит в том, чтобы включить ваше доменное имя в groupId, и я бы, конечно, не повторил его в artifactId (насколько мне известно, Spring НЕ делает что - за исключением, возможно, для артефактов OSGI?).

Вот что я использую:

Родительский (pom)

• groupId: org.companyname.projectname
• artifactId: root
• версия: x.x.x

например: org.companyname.projectname: root-1.0.0.pom

SubParent (pom)

• groupId: org.companyname.projectname
• artifactId: subcategory-parent
• версия: x.x.x

например: org.companyname.projectname: subcategory-parent-1.0.0.pom

Модуль (jar)

• groupId: org.companyname.projectname
• artifactId: modulename
• версия: x.x.x

eg: org.companyname.projectname: modulename-1.0.0.jar

И я также использую соглашения для элемента <description>, чтобы иметь чистый обзор во время сборки реактора. Вот пример проекта для домашних животных:

$ mvn compile
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   Personal Sandbox - Samples - Parent POM
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample
[INFO]   Personal Sandbox - Tools - Parent POM
[INFO]   Personal Sandbox - Tools - Shared Verification Resources
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample - Services
[INFO]   Personal Sandbox - Samples - EJB3 and Cargo Sample - Functests
[INFO]   Sandbox Externals POM

Это сильно вдохновлено Винсеном Массовым, чтобы организовать большие сборки, как он сделал с XWiki или Cargo.