Weirdness is highly subjective, I just suggest to follow the official recommendation:
Guide to naming conventions on groupId, artifactId and version
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. Look at More information
about package names.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
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
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