Version numbers in Maven

I am probably the 50th person ranting about lack of inheritance of version numbers in Maven. Those who use Maven 2.0.4 will know what I am talking about. Maven developers plan to bring a solution with the next release, i.e. 2.1. Whatever the solution, it can't be worse than using the release plug-in, the officially recommended approach at present time. The release-plugin approach is both total crap and an insult to intelligence.

Nevertheless, I am fairly happy with Maven 2. Our 3 month investment is finally starting to pay off. If Maven were a car, it would safely take you from place to place as long as you did not switch on the radio. You see, the radio feature in Maven is not meant to be actually used. It is there for show only. As soon as you attempt to tune in to some music, the exhaust will sound off a loud bang and your car will need to be towed to the nearest garage for maintenance.

If you know of a good solution to the version number problem, please share your wisdom with us, mere mortals.

logback: a worthy successor to log4j?

As you may have already heard, I have been working on a new project
called logback, intended as a worthy successor of log4j.

On the 5th of December, I'll will be presenting (in French) the top 10
reasons for migrating your projects to logback. Issues such as
migration strategy, new APIs, SLF4J and Joran will be
discussed. Emphasis will be given to practical aspects and a live demo
rather than relatively theoretical considerations.This free-entry
event is organized by Hortis.

For those who may not be able to attend my presentation, here is abrief summary:

• Logback is an improved version of log4j
• Given that logback is built on top of SLF4J, you can switch to a another logging system at will.
• The new Joran configration API sits at the core of logback.
• The Status API for accrued resilliance. Logback's status API enables internal error reporting in a simple yet powerful way without adding complexity.
• Documentation: already good and getting better by the day.
• Filtering API. If you can imagine it, logback can filter it.
• Marker objets to color log statements for highly-specialized processing.
• Access module: easy integration with access logs generated by Tomcat or Jetty
• JMX: You can configure logback at runtime using Mbeans.
• TDD: logback has been developped test first. Moreover, logback is available for use, today.

The full presentation is also available. Anyway, I hope you will be able to attend.

Repated configuration with Joran

Developers have frequently express the need to output log files based on arbitrary runtime criteria such as by client, by task, etc.

Given all the flexibility offered by logback, writing such an appender should be easy. Let us call this new appender, MultiAppender. In principle, all MultiAppender needs to do is to create a new file as necessary according to the evaluation of incoming logging events. A configuration snippet might look like:

 <appender class="ch.qos.logback.core.MultiAppender">
  <fileNameCalculator class="ch.qos.logback.core.Calculator">
    <fileNamePattern>/some/path/%exp{userid}.log</fileNamePatttern</> 
    <expression name="userid">mdc.get("userid")</expression>
   </fileNameCalculator>
 </appender>

Thanks to Joran, logback's powerful configuration API, we can deal with unknown configuration elements such as fileNameCalculator, expression and so forth. It's a slam dunk for logback, or is it?

Although Joran can deal with arbitrary configuration instructions, it can do so only once. Assume we changed the requirements, so that MultiAppender acted like a multiplexer of appenders. Thus, instead of writing to different files, it delegated to a fully-fledged appender, according to various criteria, then MultiFileAppender would need to configure a complete appender repeatedly.

We are in the process of refactoring Joran so that it can be invoked repeatedly on parts of a configuration file. To my knowledge Joran is the only configuration system offering this capability (but I might be wrong.)

In a completely unrelated project, the same need of repeatedly configuring components came up. In this other project, we need to configure a tester, an object performing one or more tests. We create a tester, configure it, invoke its test methods, collect the results, and when done, throw the tester away to start all over again a few minutes later. We leveraged the unique capabilities of Joran to provide this particular lifecycle. Joran, part of logback-core, is a generic configuration system that you can use in your own projects to great effect.

Do ping me if you need further info,