Petr Kozelka's blog

Yesterday my family was extended by a new little girl, see here:

Many thanks to my wife Martina !

In addition to the buildbox project at sourceforge, I just created parallel one at a http://buildbox.googlecode.com. While SourceForge provides a lot of useful options and services, like shell access, web site with storage etc., their wiki service is rarely functional and I had no more time to fight it. Plus the issue tracker at SourceForge is a crappy thing too, so I decided to give a chance to Google’s hosting service, currently only for wiki and issue-tracking purposes.

Very good news today: the internal repository of the buildbox project is now automatically rsynced to Maven Central Repository. This gives me an option to release artifacts in a way that allows others to use them without any special configuration in Maven.
I am going to publish only releases that make sense, so there will not be new versions from me every second day. I am just happy that I have a way to publish my artifacts
To see the buildbox artifacts, click here.

StrictLogging is a log wrapper forcing you to have your log messages catalogized. Read more at http://code.google.com/p/buildbox/wiki/StrictLogging

From changes.xml:

• StrictCatalog: StrictCatalog changed from annotation to normal interface to make use of type safety
• addition in Severity: new severity “TRACE” for temporary logging
• addition in strictlogging-javalogapi : implemented wrapper for standard java logging api
• addition in strictlogging-log4j : Log4J api wrapper isolated to separate module
• addition in PrintWriterLogger : implemented as the most lightweight yet quite complete logger
• warning in strictlogging : started at buildbox in new package and with some class renames

When you build an application, with complexity exceeding “Hello, World” example, you usually need to use classes and other resources from another library. Then you have several options how to do it:

1. (worst one) copy the sources of this library to your project. This is extremely bad idea; id disconnects you from the development of original code. Fortunately, AFAIK, this is not widely used practice
2. (very bad too) copy the necessary libraries in binary form to your version control. This practice is widely used and is main subject of this article.
3. the best and only right one is, to declare your dependency using a logical identification, and leave the rest up to your build tool.

The advantages of declaring dependencies instead of copying them into your project might be obvious to people who already use it, but the others might appreciate that:

• you can easily switch used version, without having to download any jar and properly place the resources
• you don’t waste your version control server’s disk space by abusing it for binaries
• you know and use the version of such a dependency in “live” form – you control it
• you can even define or use some transitive algorithm to select the right version, if multiple of your dependencies depend on various versions of the same artifact
• you can be very sure that you use a version published by its vendor, and not one hacked or tweaked somehow

Maven is a build tool using this approach. However, if you prefer ant, you can still work with Maven artifacts in the huge Maven repository, by using Ant tasks for Maven.

Another option seems to be using Ivy. I personally don’t have any experience with this, but AFAIK they use dependency declarations and reuse the Maven central repository mentioned above.

And of course, there are (were) DevTools with its “ante”, a build tool based on ant. It uses project descriptor with identity, dependencies, tests, and other necessary build stuff described in a declarative way. It’s a proprietary tool and only ex-Eurotel people have the chance to know it.

Personally, what I find best at explicitly declaring dependencies is that it allows other build-related tools to use that information and produce effective build schedules, reports etc. This might be offtopic if you work on your diploma task, but in serious long-term software development, it soon becomes unavoidable.

So my recommendation is: declare your dependencies in a project descriptor. Never store it as a binary under your project directory!