Suppress logback initialisation messages

Recently I noticed logback logging lots of joran messages, I'm sure it just started happening one day.

With a little playing around I believe that the messages are a symptom of the element deprecation. If you replace the layouts with the correct tags the messages go away.

I used to see this

00:52:57,820 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
00:52:57,820 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
00:52:57,821 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/michael/src/stickycode/trunk/net.stickycode.examples/sticky-example-mockwire/target/classes/logback.xml]
00:52:57,954 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
00:52:57,962 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
00:52:57,971 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CONSOLE]
00:52:58,016 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component ...
...

But by changing

 <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>info</level>
    </filter>
    <layout class="ch.qos.logback.classic.PatternLayout">
      <Pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</Pattern>
    </layout>
  </appender>

to

 <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>info</level>
    </filter>
    <encoder>
      <pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</pattern>
    </encoder>
  </appender>

All the joran/logback messages have disappeared. Yay.

Subversion, kwallet and eclipse hangs

I noticed recently that subversion had added kwallet support, awesome.

But it makes eclipse hang if you use javahl with subclipse and most like other integrations.

There are two possible solutions that i've found

1) use svnkit with subclipse

2)Or you can tell svn command line to use a different config, eclipse will store the password encrypted as well but thats ok as long as its not plain text.

I just copied my .subversion/ to .subversion-cli and added an alias to .bashrc

alias svn='svn --config-dir ~/.subversion-cli'

Finally exceptions as parameters in slf4j 1.6

Exceptional parameters

So with slf4j 1.6.0 you can do

try {
 something
}
catch (SomeException e) {
 log.error("some message {}", parameter, e);
}

That just makes slf4j that much easier to use.

Gotcha
Be aware it is ONLY the last parameter. If the last parameter is an exception the stacktrace will be logged. Looking briefly it appears that the exception remains available for replacement so

log.error("Message {} error {}", "parameter", exception)"

Would look like "Message parameter error exception.getMessage", with a trace after. Don't quote me though, try it for your self.

The old way
It used to be that the e would just be ignored which is very substandard. As you would just never know until you deployed it and it failed and you really wanted the error.

Or you would have to write

try {
 something
}
catch (SomeException e) {
 log.error("some message " + parameter, e);
}

Logback
If you use logback you should use 0.9.22 to go with slf4j 1.6.0 I found other combinations troublesome.

The correct Maven release plugin in may 2010 UPDATED

In my current contract we use subversion for source control and maven2 for release management.

Release plugin running even when there are mods
I've been using the maven-release-plugin for years without issue however recently we realised that using maven 2.1.0 and release plugin 2.0-beta-8 allowed releases with working copy modifications. This is a major drawback it means if different people makes tags of the same artifact they might be different even if made seconds apart and one of the reasons for using the release plugin in the first place.

After a day of testing different combinations i've ended up using Maven 2.1.0 and release-plugin 2.0-beta-9 with remoteTagging disabled. Why?

Why Maven 2.1.0 and maven-release-plugin 2.0-beta-9
We use ranges and release plugin v2.0 can't resolve ranges.

Maven 2.2.1 generates bad checksums for the repository metadata (or calculates it incorrectly locally) so when you are resolving dependencies you get checksum warnings everywhere, not a good look for a professional contractor to leave warning all over and build and release process. So Maven 2.2.1 is out.

Release plugin 2.0-beta-8 does not fail when there are working copy modifications.

Remote tagging. Well after thinking about that for a few minutes I realised it was a terrible idea so I switched it off.

In nearly every project I've ever worked on you don't need to generate a site for each artifact, attaching the sources is sufficient for IDE's and well they don't really have a site. If there was decent aggregation my depedencies into one site I might use it. But doing site just slows it down. All the test reports are in hudson anyway.

And then I realised it didn't work
You have to force the scm version being used too. Which is not too hard just set the dependency for the plugin

The resultant config

<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-9</version>
<configuration>
<preparationGoals>clean enforcer:enforce verify</preparationGoals>
<goals>enforcer:enforce deploy</goals>
<tagBase>${svn.repo.base.url}/tags/release/${project.groupId}/</tagBase>
<remoteTagging>false</remoteTagging>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-svnexe</artifactId>
<version>1.3</version>
</dependency>
</dependencies>
</plugin>

Eclipse is building my maven release!

Who will find this article useful?
If you want to develop with eclipse and use the maven-release-plugin, and not have to have a special working copy for doing release:prepare

Hold on I can't clean
You will find that if you use eclipse and maven and share output directories, doing a clean from the command line will trigger eclipse to rebuild the project.

Whos is really compiling those classes
It looks innocent initially but consider that eclipse is using a different compiler and classpath. Eclipse does not understand scopes for classpaths so you end up with compiler errors not being seen - i.e. class leaks from test scope for example - until someone else tries you build the project later.

How to configure it the right way using the maven-eclipse-plugin and m2elipse
You should alway configure eclipse and maven to use different output directories. See an example pom that shows how to configure the maven-eclipse-plugin to allow you to generate eclipse project files.

With that configuration you should run mvn eclipse:clean eclipse:m2eclipse



How to configure it the right way using eclipse without the m2eclipse plugin
Configure the output path to be target-eclipse/classes

How to configure when using IAM
I imagine the process would be similar to the m2eclipse plugin but I've never tried, sorry.

The release plugin is your friend
When using the maven release plugin - which you should do if you are thinking of using maven at all - makes this all the more important as the standard release process involves, clean, build, tag. If that build is done by eclipse you don't have the two factor validation i.e. command line and IDE to show you build is coherent.

Get rid of the extra working copy
A common solution is to release from a separate working directory than the one you use to develop. Its just an extra overhead you just don't need.

Hope this is useful for people out there, anything to encourage people to use the release plugin.