Great news for OSGi users/developer and those who care about a good component design, Java modules and a clean classpath. Ian Skerrett cited the quarterly OSGi newsletter on his blog:

In the time since my last e-mail to members, the OSGi Alliance has welcome two new members. One of the, Sun Microsystems, is a previous (and actually founding) member, and the other, SAP, is brand new to the OSGi Alliance. I welcome both of them and look forward to their participation and contributions to the OSGi Alliance. In fact, both of these organizations have nominated candidates for the OSGi board —

Unfortunately I have not much time to investigate into building a better Java package management system I talked (or better ranted) about yesterday. But sometimes walking rather slow means also avoiding walking too fast. There is more time for looking around. In the past I analyzed different projects and code bases, e.g. Maven, Raven and Buildr or Portage, but I didn't found a best match. Of course I'm seeing much potentials in Portage, but it's written in Python and this could be a no go for some developers.

Today I discovered the Kepler Project. Carlos Sanchez blogged about the Eclipse Summit 2007 and the need for a plugin/bundle repository for Eclipse. As he stated, one wish or idea is to use a Maven compatible repository. Kepler tries exactly that, beeing a standard package repository while preserving compatibility to other package formats. I will have to keep an eye on this project.

Today, a colleague of me tried to integrate JMatter into our Maven based buildsystem (which drives the Eclipse side too) for experimental purposes. As you will divine, this didn't went well and he finally ended with a ordinary, poor man's lib directory, which holds all the needed jars for JMatter of a size of almost 30 MB.

Stop! Why is it so hard to integrate foreign packages into Maven? I believe it is because Maven tries to address to many aspects of different domains. It tries to be a build system, a package management system, a dependency resolver and a package repository at the same time ... and it fails miserable.

On the other hand, other buildsystems like e.g. Ant ignore their dependencies completely. They simply assume those jars and classes are present somewhere somehow.

Leif Frenzel released Cohatoe 0.5, an Eclipse plugin, which allows you to write Eclipse plugins directly in Haskell. Leif wrote, that this version will have almost all planned features of the 1.0 release. This version has now an extension wizard and is able to handle running extentions from Haskell source code. It is the version Leif presented a the Haskell in Leipzig 2 meeting. Cohatoe switched its repository to the EclipseFP webspace and newer releases will only be found there.

The yesterdays second Haskell in Leipzig Meeting (HaL) was just great. As last time we reached the limits of our conference room we decided to arrange the next Haskell meeting at Victor Jara. This was the absolutely right decision. We had a pleasant ambience in the cellar of the old Leipziger Felsenkeller. The team of Victor Jara prepared us a really great conference atmosphere - so, many thanks and compliments to you, Lütti.

The first talk was hold by Johan Jeuring (Univ. Utrecht) who gave an overview over Generic Programming in Haskell. He presented a field of his actual work: Finding criteria for a standardized Generic Programming library for Haskell. At the end of this talk he gave yet another hint for this year's functional programming contest.

This is one chapter of the story of Mavens shortcomings. It's hard to understand how so many (professional) Java developers can life with these. Nearly every day I stumble over the one or another issue with this build and package management system for Java. I already wrote about the surefire-plugin [1, 2] which claims to support TestNG for a very long time now but in fact, it doesn't, at least not very well.

Although some of the issues I have with Maven seem to be annoying bugs, which could be solved somehow, others were shortcomings by design. One of those design problems is the local repository (and the idea to mix foreign packages and freshly developed packages of the current project in general).

In my search for alternatives for Ant and Maven, Raven crossed my path. Here is a somewhat lenghty comment to Matthieu Riou's blog post Builds And Transitive Dependencies.

Transitive dependencies are an essential requirement dictated by the nature of software development. Each buildsystem which claims to be a real one (including package management), has to support transitive dependencies.

The question is, at what level this support goes and how clever these dependencies are handled. Working with Maven, I can say that dependency handling cannot going worse. Comming from the Linux distribution Gentoo I'm used to a package management system (portage) which is more clever than all tools I've found for the whole Java and scripting language world in terms of (transitive) dependency management.

(this is just a reminder for myself ... to do it really and to report when I have made the first experience)

As we had more trouble with Spring, AspectJ and Maven than we want to deal with, lately, I will higher the priority of Guice and AOP as defined by the AOP Alliance on my todo list. The first candidate to be picked up in my currently developed software will be Guice. I could hardly await to get rid of those xml configuration files...

Update: I just found this video - a one hour introduction hold on the Google Tech Talks, April 26, 2007 by Kevin Bourillon and Bob Lee.

I have never seen such an bad documented commercial product like Crystal Reports Server 11. It is a real nightmare to use its Java API for programming and scheduling reports. Even those nothing-saying error messages from Oracle are rich of information compared to Crystals one.

A while ago we switched for a couple of projects from JUnit to TestNG. Everything went fine with maven and Eclipse, but yesterday I recognized while running maven clean test that the tests where found but not executed. I got many lines like these:


Running de.ibacg.XXX.dao.jpa.test.UserDaoAndRoleDaoTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.445 sec
Running de.ibacg.XXX.dao.jpa.test.StatusProtocolEntryDaoTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running de.ibacg.XXX.services.provider.test.MasterDaoProviderTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.688 sec
...

Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0


Very strange, as all these tests contain at least two test methods and are annotated with @Test on method- or class-level.