Maybe I just found an answer to my long standing need for an adequate build system for Java projects. On my web search for build systems I do every month in the hope that I can avoid to (continue to) develop my own one, one week ago I found a new tiny star on the build system heaven (or should I say hell): Quokka. A pretty fresh project developed by only on person, Andrew O'Malley. My first lock on it looks very promising. The project statement says it very clear:

"Quokka is a software build system, focusing on reproducible, modular builds with fine-grained dependency management."

It's focus is to be an alternative to Maven und therefore it supports almost the same directory layout for a single project. It comes with a very good User Guide and takes transitive dependency management somewhat more serious than Maven does.

Let us hope...

Lately the Maven project has been taking a lot of heat from various sources about stability and over-all quality. For the most part, they were right. The Maven team is very strong and certainly no one intends for these problems to happen, but ultimately they were.
...
During a review of the open issues while planning 2.0.10, I became aware that a significant number of open issues start with "this used to work until 2.0.[x]". I became frustrated and a little embarrassed to realize how bad of a regression problem we had going on.
At that point I decided that my personal priority for 2.0.9 had to be No more regressions.

Cited from Brian's Enterprise Blog

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.

(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.

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?

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.