Friday, April 27, 2007

[Tech] Maven: The Definitive Guide

Ok, today is the day of micro-postings, however, this might be interesting and good news for some developers. Apache Maven got a new online-book. Maven is a great tool for build-automation, a deployment tool, a dependency management tool, a documentation generator and reporting framework and is implementing build-lifecyle-best-practices and propagates the convention over configuration idea and so forth. A lot of features, a lot to know and learn. However since version 2 Maven is definitly taking off and apparently replacing Ant in many projects.

So, for all who need more information than there is provided on the Maven website, check out the two free Maven books:
I think both books are useful; up to now I mostly used the Mergere book, but it is lacking some important information, e.g., the documentation generation (site) is practically non-existent in this book, but well described in the "definitive guide." It should however be mentioned, that the "definitive guide" is apparently not completly finished yet. For example the "Mojo" chapter lacks description of mojos in Ant (which is a pity from my point of view), also Beanshell and Ruby are only available as heading. So some "TODOs" are still in the text, but it is still worth a look!

So let's hope the author(s) have enough motivation to continue the work on the book. (btw: it is funny, that I found nowhere a reference who the authors of this book would be? any ideas?!)

[Tech] Feathercast and other SE Podcasts

Today as developers we have to stay in touch with a lot of projects and technologies over some different channels. Podcasts are a meanwhile well known be most developers and also the software engineering community starts using this new communication channel. Two podcasts I know might be interesting for developers:
  • Feathercast is the "unofficial Apache Podcast". It is dealing with Apache projects, introduces new projects, makes interviews and gives an "inside" look into the Apache software foundation.
  • Software Engineering Radio is done be a group of SE professionals from Germany.
Or alternatively search for the Podcast in the iTunes Podcast directory and subscribe in iTunes, might be the easiest way.

Any more good Podcast suggestions from readers?

Sunday, April 15, 2007

[Tech] System Trays

In the current Java magazin I've written a short article about System Trays. Do you know what a system tray is? You're right, the nice icons on the rigt bottom side of your task bar (in the case of microsoft windows).

The AWT package of Java 6 already provides all necessery libraries to develop system trays. At present you can also use Java Desktop Integration Components (JDIC) a supported project of Sun. JDIC focus on desktop development, especially Swing.
All necessary components to develop system trays are located in the package org.jdesktop.jdic.tray. The class SystemTray can be seen as placeholder for the TrayIcon. This icon will be displayed in the toolbar and also contains the menu (an instance of JPopupMenu), which will be popuped if the user clicks on the icon. In order to create popup menues with Swing, please look here. Such a popup menu can then be added to the system tray by passing the menu instance to the tray icon.

You can also show messages, like outlook or skype:

The usage of system trays must be carefully planed, because many people don't like unused icons in the toolbar. A system tray can be very usefull in order to provide the user most wanted functions of your system.

Friday, April 13, 2007

[Tech] Dependency Injection with Guice


Dependency Injection is a software pattern for writing high quality testable software. The Java world recently got a new framework named Guice that was developed by Google and that provides an interesting alternative for people who fear (XML) configuration files.

If you never came across this topic, Martin Fowlers excellent article "Inversion of Control and the Dependency Injection pattern" is highly recommended.

Refresher on Dependency Injection

It's common for classes in object oriented environments, that they can't provide the requested functionality on their own, but need to use external services (classes connected using delegation). The easiest way is to create the required service is using the new() operator when needed. This will work at first but as soon as you want to replace the service with another implementation you run into problems and have to modify the code in many places (and rebuild the application). With modern refactoring tools this still wouldn't cause you a lot of headaches but when it comes to testing this approach really starts to hurt. Unit testing your object without testing the service gets impossible so a more dynamic approach for accessing the service becomes necessary.

Moreover, modern application design often prefers late-binding and loose-coupling, meaning, that some implementation details can be decided very late in the process, in many cases at the customer (e.g., which driver is uses, how a specific driver or module is configured). These configuration steps should also be feasible without refactoring of the application as this would mean a different code-basis for every customer!

You basically have two choices:

1.Using a Service Locator that creates and returns the right service implementation depending on the context.
2. Someone else provides the right service; either during construction time or by using a factory pattern during runtime and calling setter-method(s).

Dependency Injection frameworks are particularly useful if you go for the second option. You first tell the framework which implementation to use for which interface. Whenever you then request an object of that interface you not only get the right implementation, but the requested objects dependencies, and their dependencies, and so on (recursively if needed), are also automatically resolved by the framework. It's considered best practice that the configuration of the framwork happens during the bootstrapping process and a single fully configured object is requested once from the framework. Most classes are not even aware of the injection framework (at least in the case of popular frameworks like Spring).

Dependency Injection with Guice

If you're used to Spring you will be surprised, that frameworks like Guice don't necessarily need large, hard, in some cases hard to maintain, external configuration files. In Guice all your configuration is done in code and uses the annotation features of Java 1.5.

Configurations are separated in Modules by either implementing the Module interface or by inheriting from the AbstractModule class. Within the configure() method you then bind interfaces to their implementations.

public class MyModule implements Module {
public void configure(Binder binder) {



The example above is taken from the Guice documentation and binds the interface "Service" to the implementation "ServiceImpl". It also sets the service scope to be Singleton. Scopes deserve an article on their own, but basically they request a specific life cycle behavior for the object.

public class MyObject {

private final Service service;

public Client(Service service) {
this.service = service;
A class that needs a service would just add a parameter to its constructor (or define a method that takes the service as an argument) and annotate it with the @Inject annotation.
public class FooApplication {
public static void main(String[] args) {
Injector injector = Guice.createInjector(
new MyModule(),

MyObject starter = injector.getInstance(MyObject.class);

// do something useful

During application startup an Injector is created with one or more modules as configuration. It is then used to request our object. Under the hood it will 1. create an instance of the class (depending on the scope), 2. look at all methods that we declared with @Inject and 3. supply the required services (back to 1).

External Configuration vs. Code-based Injection

There are good reasons not to use Guice especially if you like configuration files. It's true that you would have to recompile at least part of your code if you change the configuration. This would become a problem if you deploy your application to many targets that need to be configured differently. On the other hand configuration in code provides huge advantages: refactoring becomes much easier, your configuration files have to stay current otherwise your build will fail, in general readability is higher, and your development environment will help you with auto completion to configure your application much more quickly. The Module concept of Guice also allows you a more hybrid way: depending on some simple eg. property file, you could pick the right module during bootstrapping of the application. Which way you choose strongly depends on the needs of your application.


We just scratched the suface of Guice but showed the ease of use of the framework. Although it doesn't have as many features as Spring, it should be considered for projects where you want to reduce XML configuration files and need a slim fast dependency injection framework.

Thursday, April 12, 2007

[Misc] Project Mailing Lists as Newsgroups

Ok, this is probably not a big issue to write about, however, sometimes small things can be quite a pain in the ass:

Working in the open-source context typically means watching a set of mailing lists of OS projects used in the own project, or watching potentially interesting projects. Mailing lists are obviously the center spot of information. However working with mailing list is not always fun:

  • For every project of interest the mailing list has to be subscribed
  • Significant email traffic is involved to the own address, so typically a special mail account has to be prepared for that purpose
  • To work properly with MLs a filter for each one should be written to pre-sort mailing from different projects into dedicated folders.
  • All that is awkward enough, but what if you want to watch some projects for a limited time, checking the status, then it means registering, unregistering, managing filters...
So, there is actually (for most cases) a much better solution, I found out many still do not know:


Is a NNTP news server, that is actually bridging mailing lists from most prominent OS projects to NNTP newsgroups. However that might technically work is not important, the point is: connect to that news-server and subsribe to all MLs of the projects of interest as newsgroup. This is very easy, unsubscribing as well, and even postings can be done, once the email address is confirmed. Mail clients like Thunderbird also support NNTP newsgroups, so no special client is required; just create a new nntp account in Thunderbird.

I personally do not know, why the very useful NNTP newsgroups are more or less dying. The technology was far better than mailing lists andparticularly better then web-forum software in the first place, but ok, at least gmane provides us this great service.

Tuesday, April 10, 2007

[Event] WebIST Conference and the SE contribution to collaboration

At the WebIST conference this year, we presented a paper dealing with instant collaboration and new patterns of team cooperation. This topic is not directly related to software engineering, however, my observation is, that best-practices that emerged within the software development context, particularly in highly-distributed open source projects "diffuse" into other areas. In this entry I write about some thoughts on groupeware and software engineering methologies.

SE Toolset and Methodologies

To be more precise: in open source projects, a set of tools and methodologies are used to develop software and manage the roadmap with teams distributed over the whole world, such as:
  • Mailing lists
  • Wikis
  • (Sourcecode) Repositories
  • Bug/Issue Tracking systems
The interesting thing is, that these tools are meanwhile also used in many companies and workgroups that have no relation whatsoever with software engineering. Subversion can be used to manage "office documents" and project information, websites and the like as well. Wikis are used for general prototyping, issue trackers like Trac are used to distribute tasks and keep track of them.

Specialised Groupware Tools?

Several attempts were made in the past to bring up more integrated tools for project/workgroup management. However, my feeling is, that the abovementioned specialised tools have a huge user basis and a lot of advantages over integrated software specialised in groupware. E.g., the capabilities of SVN is hardly reached by one of the many web-based content repositories.

So various groupware attempts failed in the past, because a complete new toolset was introduced, and typically users did not want to leave their known application-environment and work-style. Hence the groupware forum and web-repository was deserted and discussions were still made (and files distributed ) via email; despite all disadvantages.

The solution?

In many cases a good solution can be the installation of proven software-engineering related tools even in non-SE domains. Still, the problem persists, that different types of users with different skills want to work with these tools, and the integration between those applications is typically rather weak (particularly from the standpoint of a not so skilled user). So generally spoken, I see a significant "market" for integration software, that actually uses established repositories, content management systems, instant messaging protocols and so on, but helps to integrate those with unified user interfaces for different target audiences.

Additionally we still face the problem, that a good toolset has to be used! The hardest part in establishing a groupware strategy is not the installation of the tools, but the "refactoring" of the usual work-processes. I.e., bringing the users to actually using the new software appropriately.

Establishing Groupware = Software Installation?

The suggestion here is to bring the collaboration tool to the user not vice versa: This user can be a developer who uses an advances SVN client or a command line toole, but can at the same time be a user management with less technical skills. First successful steps can be seen with the success of SVN because of good Explorer plugins. This "simple" plugin is in my opionion one of the main reasons, why SVN gets grip outside the "core development teams".

Additionally various channels, now separated, can be used on similar channels. In our paper we suggest for example, a system, where resources are exchanged via instant messaging plugins, but are actually held in a reliable backend repository like Daisy or WebDAV or SVN. Another thought is, to bring IM and resource access and exchange technology into email clients. Then users could share documents in their "favorite style", namely using the mail client, but they would actually be exchanged e.g., via SVN and not via SMTP. The advantage is clear: the user has his or her familiar environment, but in the backend a more stable solution is established (versioning, access via various systems, e.g. content management...)

This strategy should reduce the gap for the user between his old environement and work-processes and new processes and tools. Later on, more advanced tools can still follow when required.

Any thought to this connection between SE practices and general collaboration? Particularly considering different audiences?