'Convention for maven properties: "dot case" or "camel case"?

Using java and Maven, what is the convention for maven properties?

I am posting 2 examples here, both of which are in widespread usage. Which one is correct, according to convention?

Example A

<properties>
    <hibernate.version>4.3.8.Final</hibernate.version>
    <hsqldb.version>2.3.2</hsqldb.version>
    <log4j2.version>2.0.2</log4j2.version>
</properties>

Example B

<properties>
    <hibernateVersion>4.3.8.Final</hibernateVersion>
    <hsqldbVersion>2.3.2</hsqldbVersion>
    <log4j2Version>2.0.2</log4j2Version>
</properties>

Edit:

Here is a link to a Maven Properties Guide. Some examples of maven properties include ${project.build.directory} (dot case) and ${project.build.outputDirectory} (both dot case and camel case).

And the official documentation Maven POM Reference suggests an example property named <someVar> (camel case).

javamavenpropertiespom.xmlcamelcasing


Solution 1:[1]

After reading the relevant documentation, the answer to this was clear all along.

The apparent conflict between dot.case and camelCase is that one is used to reference the hierarchical structure within the POM whilst the other is used for variable naming.

For example, let us look at ${project.build.outputDirectory}. The dot notation here, as far as I can understand, refers to the pom structure where the variable is located, whereas the variable name itself is indeed in camel case.

<project>
  <build>
    <outputDirectory>/opt/foo</outputDirectory>
  </build>
</project>

In other words, the convention is as follows:

  • To refer to variables located elsewhere in the POM, combine path segments such as project or build with the . separator, i.e. use dot.case. Examples:
    • project.build.<variable>
    • maven.compiler.<variable>
  • To name the actual path segments, including the variable name itself (last segment), use lowerCamelCase. Examples:
    • outputDirectory (as in project.build.outputDirectory)
    • target (as in maven.compiler.target)

It is worth noting that most open source projects (including e.g. Spring Boot, pre-Gradle-migration - see here) use .version as a path segment and not as an addition to the variable name.

Consistency is the most important consideration. If your codebase is using someDependencyVersion, stick to that - else prefer someDependency.version.

Solution 2:[2]

I may be late to the party, but here's my 2 cents.

Consider you may want to check if there's a newer versions available. You have to find each dependency reference within the pom to know the library's groupId and artifactId.

On the other hand, if you use a naming convention shown below, you immediately know whether the version is a reference to a groupId or an artifactId and you can just copy-paste it and search for latest version.

<properties>
    <ch.qos.logback.version>1.2.5</ch.qos.logback.version>
    <logstash-logback-encoder.version>6.6</logstash-logback-encoder.version>
</properties>

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Paul Benn
Solution 2 Mikko Tuominen

Related Questions