<wurbletDependencies>
  <wurbletDependency>
    <groupId>org.example</groupId>
    <artifactId>example-wurblets</artifactId>
    <version>1.0</version>
  </wurbletDependency>
</wurbletDependencies>

wurbletDependencies versus plugin dependencies
Wurblets can also be added to the <dependencies> of the plugin declaration. They are then loaded by the plugin's classrealm itself. Maven creates this realm only once per build and caches it, so all modules and all executions of the build share the same wurblet classes and thus the same static state, such as models, caches and other singletons. In that case org.wurbelizer.wurbel.WurbelContext.getWurbletClassLoader() returns null. With wurbletDependencies, on the contrary, each execution gets fresh classes with fresh static state. Different modules may even use different versions of the same wurblet artifact.

Wurblets built in the same reactor
If the wurblets are compiled with the wurbile goal in a module of the same multi-module build, the wurbletDependencies are resolved from the reactor at the time the consuming module is wurbeled. Hence, the wurblets just built are used and not a stale copy cached in the plugin's classrealm or in the local repository.
However, Maven does not interpret the plugin's configuration when it determines the build order of the modules. Unlike a plugin dependency, a wurbletDependency does not make the consuming module depend on the wurblet module. In a sequential build, the order of the <modules> usually hides this. In a parallel build (mvn -T ...), however, only declared dependencies count, and the consuming module may start before the wurblet module is built. It then picks up an outdated artifact from the local repository or fails. Therefore, the consuming module should additionally declare a regular dependency on the wurblet module to enforce the build order. With type pom and scope provided, the dependency affects only the build order and does not put the wurblets on the compile classpath:

<dependency>
  <groupId>org.example</groupId>
  <artifactId>example-wurblets</artifactId>
  <version>1.0</version>
  <type>pom</type>
  <scope>provided</scope>
</dependency>

Parallel builds and thread safety
Wurblets that are not thread-safe are executed one at a time within the JVM, even if Maven builds several modules in parallel. Only wurblets returning true from isThreadSafe() run concurrently. Since each execution processes its sources sequentially, wurblets that keep their state in singletons are thread-safe nonetheless, as long as they are isolated in the classloader of the current execution. This holds only if they are loaded via wurbletDependencies. The wurblets can check that at runtime:

@Override
public boolean isThreadSafe() {
  ClassLoader loader = WurbelContext.current().getWurbletClassLoader();
  return loader != null && getClass().getClassLoader() == loader;
}