No more commons-logging

Update 2007-10-10: No-commons-logging has been superseded by (backward compatible) Version 99 Does Not Exist.

Disclaimer
COMMONS-LOGGING VERSION 99.0-does-not-exist IS NOT IN ANY WAY AFFILIATED WITH THE ORIGINAL DEVELOPERS OF COMMONS-LOGGING NOR WITH APACHE.

Why no-commons-logging?
If you are using Maven you'll know it is practically impossible to move away from commons-logging (with its class-loading problems) and migrate to SLF4J. About every second pom declares it is dependent on commons-logging. Unfortunately Maven does not provide an easy way to exclude a certain package throughout your project. You will have to exclude commons-logging on each and every dependency you need (including transitive dependencies).

No-commons-logging is a Maven hack that allows you to exclude commons-logging from your application with a single piece of configuration.

How does no-commons-logging work?
No-commons-logging is a Maven2 package that mimics a commons-logging package with a high version number, but without any actual java code in the jar. This trick works because Maven allows you to specify a specific version for a dependency, and that version will then be used regardless of other dependency specifications.

Update 2007-07-22: Added package to mimic commons-logging-api as requested by Olivier Lamy.

How do you use no-commons-logging?
In your pom.xml include the following piece of xml:

<repositories>
    <repository>
        <id>no-commons-logging</id>
        <name>No-commons-logging Maven Repository</name>
        <layout>default</layout>
        <url>http://no-commons-logging.zapto.org/mvn2</url>
    </repository>
</repositories>
<dependencies>
    <!-- use no-commons-logging -->
    <dependency>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
        <version>99.0-does-not-exist</version>
    </dependency>
    <!-- no-commons-logging-api, if you need it -->
    <dependency>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging-api</artifactId>
        <version>99.0-does-not-exist</version>
    </dependency>
    <!-- the slf4j commons-logging replacement -->
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>jcl104-over-slf4j</artifactId>
        <version>1.4.2</version>
    </dependency>
    <!-- the other slf4j jars -->
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.4.2</version>
    </dependency>
    <!-- using log4j as backend -->
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
        <version>1.4.2</version>
    </dependency>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.14</version>
    </dependency>
</dependencies>

Disclaimer
COMMONS-LOGGING VERSION 99.0-does-not-exist IS NOT IN ANY WAY AFFILIATED WITH THE ORIGINAL DEVELOPERS OF COMMONS-LOGGING NOR WITH APACHE.

(Pre-)announcement: transport-smtpin, an embedded e-mail server for Mule

I am proud to (pre-)announce the open source project: transport-smtpin. Transport-smtpin acts as an embedded e-mail SMTP server for the Mule ESB implementation. Under the cover transport-smtpin uses SubEthaSMTP Mail Server (the last freaking java SMTP implementation).

I'll post a download location as soon as I am convinced the implementation is stable (should not take long). Please let me know if you are interested. It will be released under something like the Mozilla Public License Version 1.1.

Update 2007-07-16: This code was sponsored by Uzorg BV.

Update 2007-07-17: A project proposal was made on MuleForge.

Update 2007-8-12: The project has been accepted by MuleForge: mule-transport-smtpin project page. There is no code there yet. It seems to work for me, but not all features are thoroughly tested, nevertheless I'll try to upload the code this week so that more people can play with it.

A bit of history
Transport-smtpin came about when I was searching for a way to directly receive e-mails. In the Dutch health-care a much used standard (mis-)uses e-mail as a request-response protocol: the OZIS standard. The actual messages are in an attachment and are defined by one of many Edifact variants.

In the system I am currently working on, there is actually a person waiting for the answer in such a OZIS request-response cycle. So receiving the responses by polling a POP server would incur an unacceptable overhead.

In an earlier attempt to get e-mail directly we used Apache James. Our mailet installed in James passes received e-mails immediately to our ESB with a Hessian web service. Though writing a mailet is quite easy, this set-up has some serious disadvantages:

• Installing and configuring James for this task is not easy nor straightforward.
• In a cluster, we need to either install one James per cluster node, or devise some way to redirect e-mails to the right cluster node.

In an attempt to get rid of James I stumbled upon SubEthaSMTP Mail Server. SubEthaSMTP is a quite easy to use SMTP server implementation.

As we are using Mule, it would be neat if SubEthaSMTP could be configured as a transport. It took me 3 days (mostly to read Mule documentation), but the result is there: my very first open source project.

Making a site within 1 hour

Pardon my little pause on this blog. I just got a son: Milo. Feel free to look at Milo's website. I build it with Radiant. It took me, including the first content, less then 1 hour!