Using Your Own Stuff Is Good

Using your own stuff is good! Nothing remarkable about that, almost every developer would agree on that. In fact this is how Microlog once was created. It was created out of a real need and I used it extensively from the beginning. As years has gone by, a lot of contributions has been made. The philosophy behind Microlog is that there should many different logging destinations, each suitable in its on special situations. Which logging destination you choose is a matter of taste and the technical circumstances. As a consequence I tend to use a small portion of Microlog, beside the core classes.

The project I am currently involved in has been running for several months before I joined. The initial team has been wise enough to choose Microlog. When I joined the project, Microlog V1.1.1 was used. Yesterday I was given the assignment of logging some low level details, that potentially could create a lot of logging output. To be able to control the logging with fine granularity, I needed the newest and hottest version of Microlog. Its support for hierarchical loggers, makes it possible to set different logging levels on different classes. In my case I wanted to use TRACE for one class, but DEBUG for the rest of the classes. In my own projects, I usually only import the classes that I really need and leave the rest out. In some cases I have used the binary version of Microlog and ProGuard to keep the packaged Microlog classes to a minimum. The current project is different, Maven is used for building. As such it uses a repository for its jar files.

I added Maven code to use the latest version of Microlog snapshot. When I used it on my own computer this worked like a charm, but one of my colleagues complained that he could not perform a build. It was missing a jar file from the Microlog repository. As it turned out, this jar was missing. It was available for Microlog V1.1.1, but not for the latest snapshot build. It was very easy to solve, just copy a directory and the repository was working the way it should.

Other problems emerged when configuring Microlog. The original idea was that the new PropertyConfigurator should be backward compatible, in order to make it easy to upgrade from Microlog 1.x.x to Microlog V2.0. I found one bug; a property name had changed. This was also easy to fix. Another deploy and the repository contained the fix. The other problem is that I have re-structured the packages, which means that all the appenders and formatters properties have changed. The re-structuring is very important, so I plan to keep the new package names. Although they break the backward compatibility. But since I have changed the major version number, I am not obliged to be 100% backward compatible. When writing this, a new idea has popped up in my head. Maybe I should implement a converter that converts from the old property format to the new property format. Is this a good idea? What do you think?