16

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).

vikingsteve
  • 38,481
  • 23
  • 112
  • 156
  • Try asking on http://programmers.stackexchange.com – Bohemian May 18 '15 at 07:56
  • While it's pretty common to use camelCase in XML tag names, all of the projects I've worked on use what you're (incorrectly) calling snake case (snake_case_is_like_this). This is probably since in an actual `.properties` file, you'd use a java package name as a prefix for your properties, so you'd have `com.mydomain.mypackage.myclass.myproperty` as the property key. – beerbajay May 18 '15 at 07:58
  • @beerbajay Thanks for the input. Problem with camelcase is that it seems to conflict with some built in maven properties, like `project.build.sourceEncoding` and `project.version` – vikingsteve May 18 '15 at 07:59
  • 2
    @Bohemian Programmers Exchange, really? this is not a "conceptual" question - it is concrete in the context of maven dependencies for java projects. Can't see that it's not a good fit for this site. – vikingsteve May 18 '15 at 08:02
  • 1
    Is this not just a matter of taste? – Jean-François Corbett May 18 '15 at 08:20
  • Only in the absence of a defined convention... is there such a convention? Please don't let me go away thinking this is another case of "big-endian" / "little-endian" ;) – vikingsteve May 18 '15 at 08:36
  • 1
    Look at [Reflection Properties](http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide#MavenPropertiesGuide-ReflectionProperties). – Aleksandr M May 18 '15 at 08:43
  • @Bohemian when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) – gnat May 18 '15 at 19:13

2 Answers2

14

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.

Paul Benn
  • 1,911
  • 11
  • 26
vikingsteve
  • 38,481
  • 23
  • 112
  • 156
0

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>