How to kill your project with Maven on the example of log4j

von

I recently jumped into the well known log4j project and made a release (v1.2.17). This was utter pain. Not only that I lost more than 8 hours to set up my build environment: it took weeks to get the necessary votes because everybody of the testers needed to do the same. After all one can say a release is so expensive, that it is pretty likely that we do not get enough testers/voters at a specific time.

Why is it so “expensive” to release log4j?

What is “expensive” in an Open Source project? I actually mean the time of us volunteers we need to spend. I am a freelancer and work on Time & Bill. Really this eats up all my time I have. Working one hour on an Open Source project means I earn one hour less or I have less features in my time tracker. Open Source is fun and usually you learn a lot, this is why we Open Source addicts pay this price. Still you can calculate in money. That’s why I say expensive even when no one does pay me for my job.

Apache log4j is an old project. It has passed the age of 10, born somewhere in 1999. The build system has grown with the requirements. Think back: before 10 or 15 years, how did your build system look like? Did you even have one? There was Ant, then there was Maven. But there was either a lot of bugs or no experience. This all lead to a highly complex build. Even when some people say Apache Maven is a complex tool (it is, but it’s totally do-able to work with it) it is definitely not the fault of Maven. The Apache log4j build is so complex because things were about to grow! You can’t even blame the original devs for it. You could only say the build system needs a refactoring from time to time, and this hasn’t happened.

The past years Apache log4j remained very quiet. But now the project is about to revive, mostly because the actively developed Apache log4php project which is followed by the promising successor of log4j 1, namely log4j 2 (surprise). The latter one is for sure great code to work with. But so far it is in Alpha (helping hands are always welcome) and so we still have to maintain log4j 1.

Kill your project

Lets look at how you get your committers shocked and your voters going to vanish in a few simple steps.

Platform dependence

Java is plattform independent, but the log4j build is not. Within the build you can find that a Windows dll is created. This is done using “Windres” or “MinGW”. The recommended approach to build it is using Ubuntu. One of the log4j committers tried to recreate this build on Windows but it seems he didn’t succeed. I tried to do it on a Mac, but ended up with using a Ubuntu VM. Another one managed to build it all on his Mac. Lucky guy.

Use Maven in combination with other build tools

If you are using Maven, use Maven. The log4j build is done in Maven. Maven uses Ant. Only a few more lines are needed to build everything in Ant too. Ah, don’t worry, because the Ant build does need some portions of Maven. Still unsure how this is going to work, but it does. At the moment of this writing it is possible to release log4j with Ant as well as with Maven. This does indeed means you have to take care on version numbers 2 times.

Forget the standard layout, it’s just for babies

The Maven standard layout is there to organize your code. If you want to scare everybody, change it! In log4j it is for example not src/test/java, it is actually tests/src/java. Not sure what the benefits are, my guess is this came from history: first there was the Ant build and people found this layout a good idea. Then Maven came up with some kind of a standard, but the devs didn’t update their layout. Actually I think it is pretty nasty from the Maven devs to allow us to change the standard layout. Want to kill or lose your job? Change the layout.

Use plugins you don’t use

Apache log4js pom.xml is more than 500 lines long. It does for example contain reporting plugins which are not used. Look at the reports page, and then compare it to build. There is the Clirr maven plugin or the Rat Maven plugin which never appear on the website. Actually I haven’t checked these reports even when they are there: i didn’t knew about their existence. Either use them or remove them, they just blow the pom.xml. Well, we need to decide.

Integrate plugins you have no clue about

Apache log4j provides an OSGI plugin. It uses the Felix Maven artifact. Nice. There are a few bugs around it. Not so nice. I don’t know anybody who actually knows about OSGI. At least, it’s not me. Time to call the log4j-dev list if there is a hidden reader who knows how to fix these issues. If you are the one: please let us know.

Deploy your site to localhost

In Apache world, people are told they need to generate the site, commit it somewhere and afterwards go the Apache servers doing a “svn up”. This has some reasonable infrastructure background. However in log4j world it is done with generating the site and then committing it to localhost. This does mean you have to deal with openssh and set up your certificates on your local box correctly. Not sure how this is done in Windows. I managed it somehow, but I am honest: it took me ages, because the error messages are not really giving me anything and… ah, do it if you want to make people cry.

Make your artifact HUGE

Writing a small server lib does not prevent you to add some Swing classes inside. Do it. I am a loser because I deleted two different swing clients from the log4j artifact today. There were not test cases or instructions how to use them, so this was easy. Anyway if you want a junior developer to quit his job, just put unexpected classes into your code. Don’t use multi module projects at all, put everything into one project. People will never complain because they always think they are just to stupid to understand it.

Include and exclude tests manually in the pom.xml.

Without giving an reason. I am still gazing at it. Poor me.

Do something weird with Ant

You have Ant installed, then do something with it. Compile test classes, execute tests whatever. Don’t mind if you could do the same with Maven. Tag sites, release something do anything you want with the great and mighty MAVEN ANT PLUGIN!!!! It’s the power! And don’t forget to add tons of dependencies! Remember: Maven is just another wrapper around Ant (and this was true in Maven 1 days, when I remember correct).

You want to help us?

You are welcome! Please join the log4-dev Mailinglist with sending a blank e-mail to log4j-dev-subscribe@logging.apache.org. Make sure you have read the “Get Involved” guide. We need you, and yes, there are chances to become a committer of log4j yourself. There are not only nasty parts of this project. There is log4j 2 coming, and this is damn nice. If you prefer that to help, subscribe to the mailing list I just mentioned. Again, this no rant against the the original devs or Maven or Ant. This is a rant against historical grown software. And it is a call for help. And an invite to join our community. There are good reasons besides cool code and cool people: we try to met up on the next ApacheCon and drink a beer.

So, what are you waiting for?

Tags: #Apache #Apache log4j #Java #Maven #Open Source

Newsletter

ABMELDEN