Feb 23, 2010

Starting the 3.0 development of Microlog?

What should it take to upgrade Microlog to 3.0? A while ago I release V2.3.4 of Microlog. There was only one "small" change, the Microlog instrument and instrument example modules were activated once more. They had not been part of any previous 2.X release. But was it a good decision to make only a patch release for such change? I must admit that I think this was an incorrect decision. The change was big enough to make a minor release or even a major release. What should I do to solve the situation right now?

I think the best solution would be to make a major release, that is that I should make a Microlog V3.0. This makes it possible to make some other changes that I wants to do. The changes that first comes to mind are these:
  • Add the logging level NONE.
  • Remove the Android module
  • Remove the Amozon S3 module
  • Cleanup the PropertyConfigurator
  • ?
Some explanation might be in place. Adding the Level NONE gives the possibility to stop the logging without removing the logging from the code. This is sometimes used for production builds, with the possibility to enable logging after distribution. The feature has been asked for many times. To be honest I do not remember why this has not been implemented before.

Removing the Android module is for obvious reasons, since we have forked the Android parts this is no longer necessary to keep in the Microlog project. But is might not be obvious why to remove the Amazon S3 module. For me this was an experiment, but not something that turned out well. It is big and clumsy. A 3rd party library is used for the SOAP communication which also adds to the size. Fortunately it is kept in a separate jar. Thus only developers using the Amazon S3 modules are affected by this. Another drawback is that we need to maintain this module. I feel that I rather spend time on maintaining the core and other modules that are more important. But this is something that certainly is worth discussing. What do you think?

Cleaning up the PropertyConfigurator is something that I have wanted for a while now. When adding the hierarchical logging support in V2, I kept the original configuration possibilities. This is not wrong. However there are parts in the code that could be shared between the Microlog classic configuration and the new configuration. The parsing of attributes could be replaced by a separate StringTokenizer. All in all I think that the size of the configuration classes could be slimlined.

I guess that there are some more parts that could be improved and/or added to the list for Microlog V3. This was all that I could think of right now. Do you have any suggestions?

    8 comments:

    Jarle Hansen said...

    I don't really know what the s3 module contains, but I do agree with your argument of removing code that is hard to maintain and hardly used. Also, adding the log level NONE does make a lot of sense.

    I do not actually have any suggestions to add new functionality, but a code cleanup and maybe a detailed test review could be a good idea. Running a test coverage tool and seeing what parts of the code the tests does not currently cover.

    My Open Source Software Development Blog said...

    +1 Code cleanup
    +1 Test review

    Good suggestions!

    Software Development India said...

    I think the best solution would be to make a major release, that is that I should make Software Development.Thank you

    Software Development India said...

    I think the best solution would be to make a major release, that is that I should make Software Development.Thank you

    My Open Source Software Development Blog said...

    That is exactly what I am planning to do. Please be patient and a 3.0 release will be available on a website near you :)

    My Open Source Software Development Blog said...

    Thanks! :)

    Alok said...

    Thanks a lot.. :):)

    My Open Source Software Development Blog said...

    I try my best. Sorry to say I have little time to spend on the Microlog project.