I'll try to explain the options by going through your list :) 1.) Test project's pom.xml - This allows addon versions to be resolved if no version is specified in the test's @AddonDependency annotation. 2.) Addon project's pom.xml - This adds the addon as a dependency to the addon itself, and all addon-dependency rules from the documentation apply: https://github.com/forge/core#what-scope-should-my-addon-dependencies-be 3.) Parent project's pom.xml - This would add the dependency to all sub-projects. You definitely don't want to do this. 4.) As @AddonDependency annotation of the getDeployment method - This tells the test-harness to deploy the specified addon before running the test case. We should probably renamed this to @AddonDeployment(...). If the version is not specified, it will attempt to resolve against the current project's pom to find the version that is being included by the build. (Allows you to keep tests up to date with the POM more easily.) 5.) As parameter of ShrikWrap's addAsAddonDependencies method - This is what actually adds the addon as a dependency of the addon you are bundling (typically the test case itself). It is the equivalent of adding a dependency to the addon/ project's pom.xml file, but for the test case, not the addon. On Tue, Oct 8, 2013 at 4:53 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com&gt;wrote: -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."