Using Logback with Spring

The mandatory logging dependency in Spring is the Jakarta Commons Logging API (JCL). The nice thing about commons-logging is that you don't need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short).

Unfortunately, the runtime discovery algorithm in commons-logging, while convenient for the end-user, is problematic. Switching off commons-logging is easy: just make sure it isn't on the classpath at runtime.

<dependencies> 
  <dependency> 
    <groupId>org.springframework</groupId> 
    <artifactId>spring-context</artifactId> 
    <version>${spring.version}</version> 
    <exclusions> 
      <exclusion> 
        <groupId>commons-logging</groupId> 
        <artifactId>commons-logging</artifactId> 
      </exclusion> 
    </exclusions> 
  </dependency> 
</dependencies> 

Now this application is probably broken because there is no implementation of the JCL API on the classpath, so to fix it a new one has to be provided.Logback is very powerfull logging framework and is intended as a successor to the popular log4j project. Logback implements SLF4J api so we need slf4j-jcl brindge on classpath.

Final dependencies are:

<dependencies> 
  <dependency> 
    <groupId>org.springframework</groupId> 
    <artifactId>spring-context</artifactId> 
    <version>${spring.version}</version> 
    <exclusions> 
      <exclusion> 
        <groupId>commons-logging</groupId> 
        <artifactId>commons-logging</artifactId> 
      </exclusion> 
    </exclusions> 
  </dependency> 
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>${jcl.over.slf4j.version}</version>  
  </dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${logback.version}</version>
  </dependency>
</dependencies> 

Maven properties

Maven properties can be used in pom.xml file or in any resource that is being processed by the Maven Resource plugin’s filtering features. A property is always surrounded by ${ and }.

Built-in properties

• ${basedir} represents the directory containing pom.xml
• ${version} equivalent to ${project.version} 

Project properties

All elements in the pom.xml, can be referenced with the project. prefix. This list is just an example of some commonly used elements:

• ${project.build.directory} results in the path to your "target" directory.
• ${project.build.outputDirectory} results in the path to your "target/classes" directory.
• ${project.name} refers to the name of the project.
• ${project.build.finalName} refers to the final name of the file created when the built project is packaged.
• ${project.build.sourceDirectory} results in the path to your "src" directory.

Local user settings

Similarly, values in the user's settings.xml can be referenced using property names with settings. prefix.
${settings.localRepository} refers to the path of the user's local repository

Environment variables

Environment variables can be referenced using the env prefix,  ${env.PATH} returns the value of system's PATH variable. Any property which can be retrieved from the System.getProperty() method can be referenced as a Maven property. For example, ${java.home} specifies the path to the Java installation directory.

Parent Project variables

How can parent project variables be accessed? You can use the prefix: ${project.parent}.

Building project without running test

Next information refers to maven surfire plugin. If you want to disable tests to be run while building your project you have two options to utilize:

• -DskipTests skips project's tests, but compiling them.
• -Dmaven.test.skip skip all tests and even doesn't try to compile them.