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.

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.

Maven 2.0.6 is out and it seems it fixes some problems. One really annoying issue with at least the last release 2.0.5 was, that maven tends to ignore some test in projects which subprojects contains both JUnit and TestNG test. I wrote about that problem and a solution if you are in the affected project, but the problem re-appears if you are building not from within the same directory level, e.g. one level up in the parent project. This seems to be fixed now...

No, it isn't. Does anybody know how to get all test run in a mixed unit test framework project?