Description

Naming

Naming conventions are based on Maven's Guide to naming conventions on groupId, artifactId and version

When you create new module, there are entities that require consistent naming:

• Folder structure that leads to module location
• In pom.xml
  • project.groupId
  • project.artifactId
  • project.name
  • project.version

Leaf module folder name

• Only lower case English letters and "-" sign are allowed.
• Folder name must not duplicate information carried in the parent folders
• Folder name must be singular

project.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 (see More information about package names.)
• Package name must be singular
• Has to be at least as a domain name "org.xwiki" followed by corresponding module name.
• A good way to determine the granularity of the groupId is to  use the project structure. That is, in a  multiple module project, it should append a new identifier to the  parent's groupId eg.

project.artifactId

is the name of the jar without version

• Only lower case English letters and "-" sign are allowed.
• Must uniquely identify the artifact when resulting jars end-up in libraries (since artifact ID is the same as resulting jar  name). So artifact id is constructed based on folder structure.
  <project-name>-<top-level-module-name>-<sub-module-name>-...-<leaf-module-name>-<qualifier>
  for XWiki project always <project-name>=xwiki. E.g. xwiki-plugin-archetype-parent

Based on type of the module output it might be appended with corresponding qualifier.

project.name

Name is a more literate view of atrifact ID and is helpful during  project build to distinguish which module is currently built.

• Allows upper/lower case English letters, white-spaces  and "-" sign.
• Words start with upper-case letter
• It's being constructed as
  XWiki <top-level-module-name> - <sub-module-name> - ... - <leaf-module-name>
  e.g. XWiki Plug-in - Sample - Publishing - News Harvester

Based on type of the module output it might be appended with corresponding suffix

project.version

project.description

While optional, still much recommended to add a good description to module general purpose and responsibilities.

Samples

Let's imagine some hypothetical plug-ins module, providing plug-in archetypes and several implementation samples. All implementations depend on parent plug-in archetype.
Table below illustrates the rules