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:
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
On Tue, Oct 8, 2013 at 4:53 PM, Ivan St. Ivanov <email@example.com>wrote:
As you might know I am working on the Git tools plugin migration to Forge
2.0 addon. I reached the point of migrating the tests and am trying to
understand how to declare the dependencies of the test to the current and
to other addons. I see five ways to do that:
1) In the test project's pom.xml
2) In the addon project's pom.xml
3) In the parent project's pom.xml
4) As @AddonDependency annotation of the getDeployment method
5) As parameter of ShrikWrap's addAsAddonDependencies method
Should I declare all my dependencies in those five places? Or there is a
difference between them. I need to understand especially the difference
between 4) and 5) and why do we need them both.
forge-dev mailing list
Lincoln Baxter, III
"Simpler is better."
att1.html.zip 1.4 KB