[maven-site] branch master updated: Reversed domain name group IDs are a convention

[hb...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

hboutemy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git


The following commit(s) were added to refs/heads/master by this push:
     new 38c6c14  Reversed domain name group IDs are a convention
38c6c14 is described below

commit 38c6c14cb56de58457d85aa97c4d462ce1626998
Author: Elliotte Rusty Harold <el...@users.noreply.github.com>
AuthorDate: Tue Feb 12 07:15:53 2019 -0500

    Reversed domain name group IDs are a convention
    
    @hboutemy
---
 content/apt/guides/mini/guide-naming-conventions.apt | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/content/apt/guides/mini/guide-naming-conventions.apt b/content/apt/guides/mini/guide-naming-conventions.apt
index 705ffc3..1b6470b 100644
--- a/content/apt/guides/mini/guide-naming-conventions.apt
+++ b/content/apt/guides/mini/guide-naming-conventions.apt
@@ -30,14 +30,18 @@ Guide to naming conventions on groupId, artifactId, and version
 
  []
 
- * <<groupId>> uniquely identifies your project across all projects,
- so we need to enforce a naming schema. A groupId must follow Java's package name rules. This
- means it must start with a reversed domain name you control. You can create as many subgroups
- as you want. Look at {{{https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7}
- More information about package names}}.
-
- eg. <<<org.apache.maven>>>, <<<org.apache.commons>>>
-
+ * <<groupId>> uniquely identifies your project across all projects.
+ A group ID should follow {{{https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7}Java's
+ package name rules}}. This means it starts with a reversed domain name you control. 
+ For example,
+ 
+ <<<org.apache.maven>>>, <<<org.apache.commons>>>
+ 
+ Maven does not enforce this rule. There are many legacy projects that do not follow
+ this convention and instead use single word group IDs. However, it will be difficult
+ to get a new single word group ID approved for inclusion in the Maven Central repository.
+
+ You can create as many subgroups as you want.
  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>>>. For example,