result = dependenciesResolver.resolve(request);
        } catch (DependencyResolutionException e) {
            result = e.getResult();

            /*
             * MNG-2277, the check below compensates for our bad plugin support where we ended up with aggregator
             * plugins that require dependency resolution although they usually run in phases of the build where project

 * information among plugins, is this more like an extension point - do we need a sort of bus for
 * application data - do we need a dictionary for our applications like Apple does. We could easily
 * hook into this and this is the model we need to follow - how many of our REST services do not map
 * directory to a method in the application interface?
 *
 * - research extension points versus plugins
 *

                    </execution>
                </executions>
            </plugin>
            <plugin>
                <!--
                A plugin which uses the JUnit framework in order to start
                our junit suite "AllTests" after the sources are compiled.
                -->
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${surefireVersion}</version>
                <configuration>

     * of the child. The general idea is to adjust inherited URLs to match the project layout (in SCM).
     *
     * <p>This calculation is only a heuristic based on our conventions.
     * In detail, the algo relies on the following assumptions: <ul>
     * <li>The parent uses aggregation and refers to the child via the modules section</li>
     * <li>The module path to the child is considered to