FORGE-1030: Added documentation about what needs to be done to utilize m...

docs/plugin_development/reference-libraries.textile

@@ -18,7 +18,37 @@ bc(prettyprint linenums).. <forge>
 
 p. This will cause Forge to bundle all dependencies for your Plugin in the Plugin module itself, instead of creating a separate "dependencies" module, with a separate ClassLoader.
 
-p. *Note!* When you configure Forge to use the "dependencies-as-resource-root" option, your project must explicitly import any transitive Maven dependencies, as the Forge ClassLoader structure prevents transitive dependencies to be "seen" by your plugin. A good help to find all transitive dependencies is the "mvn dependency:tree" command, which should be run in your Plugin's Maven project.
+h3. Multi-module reactors and Forge plugins
+
+p. If your Forge plugin resides in a reactor consisting of multiple Maven projects, you need to do the following to ensure that the Forge plugin can be correctly installed:
+
+# In the project holding the plugin implementation, add a META-INF/forge.xml file using the "dependencies-as-resource-root" option, as shown above.
+# Any Maven projects in the using Forge APIs must explicitly import any transitive Maven dependencies, as the Forge ClassLoader structure prevents transitive dependencies to be "seen" by your plugin. A good help to find all transitive dependencies is the "mvn dependency:tree" command, which should be run in your Plugin's Maven project. To simplify the process of importing transitive Maven plugins in several projects, define those dependencies in the dependencyManagement section of the reactor root POM. Then supply explicit dependencies without version constants in other project POMs as needed.
+# If your projects normally require unit tests to be run in order to pass the build (typically when your POMs define Maven plugins breaking the build if unit test coverage does not meet defined requirements): Add a Maven profile (called "install_forge" in the example below) which is activated by the user property "maven.test.skip" being true. Since Forge runs the plugin installation without unit tests, your maven reactor must define a profile to ensure that the Forge installer does not fail due to your unit tests not being executed.
+
+p. A skeleton "install_forge" profile should look similar to the code snippet below. This is the standard behavior of the Maven Surefire Plugin, implying unit tests are not executed in the build. 
+
+bc(prettyprint linenums)..    <profiles>
+        <profile>
+            <!--
+                Profile permitting the reactor to be built and installed without
+                any unit tests being executed. This is required since Forge's installer
+                builds the Maven project without any unit tests.
+            -->
+            <id>install_plugin</id>
+            <activation>
+                <property>
+                    <name>maven.test.skip</name>
+                    <value>true</value>
+                </property>
+            </activation>
+
+            <!-- Add definitions here to enable the build to run properly without any unit tests being run. -->
+            ...
+        </profile>
+    </profiles>
+
+h3. Using the Shade plugin
 
 As a last resort, you may also shade code into your plugin's JAR file; however, this is extremely discouraged, since you may cause ClassCastExceptions at runtime, and this increases the burden on Class scanning at boot time, because CDI will scan all classes in your Plugin JAR file.