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.
My first thought many months ago (years, to be honest) was: There must be (already) a better solution. I started to search the web and found many different attemts to solve the problem. I found many tools, written in Java or Ruby or in other languages, tools which aimed to be like GNU Make or like a Ruby based Ant. But they didn't made me happy, and I got the strengthened wish to write my own build and package management system. I'm using Gentoo Linux as my main operating system for many years and something like Gentoo's portage came to my mind. I programmed some prototypes and made some case studies and found that it could be rather hard to address all my needs. But hold one, why should I reinvent the wheel? There are already some good build systems, even Maven is a good one, if you forget the package management aspect of it. So why not going the Gentoo way and try to adapt portage to be the package management system which itselfs invokes other build system on demand?
This would solve a lot of problems I had with Maven. The biggest one is the missing separation of package descripton like name, version and dependencies and the real build system part in Maven.
While the build system is only responsible to build a package, the package description hold the package metadata which is in the simplest case only the name and the version, but for a more complex package it can be a complete recipe of the used toolchain including how to invoke another build system.
All I would need (and want) to provide for a foreign package is the package metadata. These metadata should be kept separated from the built packages (jars). All that is needed is the information where the package can be found. Whenever this package is needed, it can be download (and cached). Nothing more and nothing less. More isn't needed for dependencies.
So. my next steps of investigation are: Examine how easy/difficult portage can be modified to be used as the package management system of choice. Portage is written in Python, which isn't my favorite programming language. On the other hand there are already some portage transferings to systems like Mac OS or other Linux distributions. So, why not using portage as Java meta package management system?