Deputy is a free open source Java tool licensed under the BSD license.
It supports the creation and maintainance of complex Maven 1.x projects which are assembled from other Maven projects.
To do so it tracks down the dependencies defined in a Maven project.xml file and resolves them recursively. It comes up with the recursive hull of all indirect dependencies that can be reached when parsing the project object models of dependencies and dependencies thereof recursively. Considering the fact that artifacts a project depends on are usually available in several versions and that different dependees likely use different versions it is unavoidable that version conflicts arise in the computation of all indirect dependencies. Deputy uses a configurable default strategy plus further optional user-definable rules to decide which version to take in each conflict. The default strategies available are suited to keep up with the latest versions of projects easily. The latter makes Deputy also a good tool to update simple project.xml files that don't hold the indirect dependencies explicitly.
The necessity of using a tool like Deputy comes when using Maven to develop and manage a large array of software components that need to be assembled to full applications in a separate step and area. Suppose each software component is defined as a Maven project. Quite naturally, it will list all its compile-time dependencies to other components in the dependencies section of the project file. However, since the component is not really interested in how the dependency components themselves depend on other components in turn, it will best avoid to list those indirect dependencies in the Maven file as well. Having access to the direct dependencies is enough to build the component. Defining the dependencies of a dependency component is the job of the Maven project file of that dependency component.
The situation is different when it comes to building an assembly, i. e. a bunch of components that interact to render a full-fledged application. The assembler of such an application picks a couple of components which he wants to see being part of the application because of their features. These components are top level components from the point of view of the assembler. Additionally, the assembly must be completed by all the components the chosen top level components directly or indirectly depend upon at run-time. This is where Deputy comes into play. It finds all those indirect dependencies by recursing over all project object model files in the Maven repositories that can be reached when following the dependencies in each of these files. It starts out with the top level dependencies and stops at dependencies which have no dependencies themselves anymore. As mentioned, version conflicts are decided by Deputy on the fly using rules. Deputy doesn't guarantee by this process, of course, that the selected versions behave well when being executed in concert. However, if the assembler discovers an incompatibility in the assembled versions (by compiling all the sources of all the assembled components together or by run-time testing, for example), he can adjust the version choices by re-configuring the rules and then repeat the recursion.
It is well possible to mix components and assemblies in the dependency graph as desired. In other words, Deputy doesn't force you to define assemblies only on top of components but an assembly may also depend on assemblies, which may depend on other components and assemblies, and so on. If an assembly occurs as a dependency during the recursion, Deputy simply views it as a component by ignoring the indirect dependencies listed in the project.xml. Having said that, it is only true if the assembly is not just a container but also delivers an (artifical) artifact representing itself because it will appear as a dependency itself in the dependant project which must be processable by Maven as any other.