Subject: Java classloading, Maven, the Kauri Runtime
Warning: the description below is rather brief and assumes some knowledge of Maven 2 and classloading in Java. If interested, you can ask further questions on Kauri's discussion list.
The Kauri Runtime is the core of Kauri. It is a system that allows for modularized applications. Each module has its own Spring IoC container and its own classpath requirements. Modules can export and import services (= backed by Spring beans). Each module is hence a black box that only allows access to explictly exposed functionality. The Kauri Runtime is not unlike OSGi, though it is much simpler.
Each Kauri module jar contains a file KAURI-INF/classloader.xml describing the classpath requirements of the module. Currently this is a flat list of jars. Or more correctly, it is a flat list of Maven-style artifacts references, e.g. a {groupId, artifactId, version} coordinate. This KAURI-INF/classloader.xml file is usually auto-generated by a Maven plugin, based on the dependencies listed in the pom.xml.
The Kauri Runtime constructs a classloader per module, and one 'shared classloader' which is the parent of the module's classloaders.
The picture below illustrates this, although it is from Kauri's predecessor, called the Daisy Runtime.
If multiple modules share a classpath entry, the runtime can move that classpath entry to the shared classloader. A module can also require that a classpath entry is put on the shared classloader, e.g. in case it is an API for one of its exposed services.
And now we come to the actual task: when moving a classpath entry to the shared classloader, Kauri is unaware of of the dependencies of that classpath entry: any dependencies of the classpath entry won't be moved to the shared classloader, which might cause NoClassDefFoundException's.
The solution would be to bring some hierarchy into the KAURI-INF/classloader.xml, similar to, and generated from, the transitive dependencies known by Maven. This way, when the Kauri Runtime moves a classpath entry to the shared classloader, it can also move its dependencies.
Further hints:
