core-it-suite/src/site/apt/index.apt.vm

 -----
 Maven Core Integration Tests Suite
 -----
 Hervé Boutemy
 -----
 2011-09-04
 -----

~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements.  See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership.  The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License.  You may obtain a copy of the License at
~~
~~   http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied.  See the License for the
~~ specific language governing permissions and limitations
~~ under the License.

~~ NOTE: For help with the syntax of this file, see:
~~ http://maven.apache.org/doxia/references/apt-format.html

Maven Core Integration Tests Suite

  This module provides the {{{./testapidocs/org/apache/maven/it/package-summary.html}effective Core Integration Tests suite}},
  starting with {{{./bootstrap.html}bootstrap}}.

* Running the Core ITs

  By default, the project just packages the tests in an artifact. To actually run them, activate the <<<run-its>>> profile:
  
+----
mvn clean test -Prun-its
+----
  
  This will subject the Maven version running the build to the integration tests.
  
  If you would like to test a different Maven distribution, you can use the <<<mavenHome>>> system property to specify the
  path of the Maven distribution to test:
  
+----
mvn clean test -Prun-its -DmavenHome=<maven-under-test>
+----
  
  Alternatively, you can just specify the version of a previously installed/deployed Maven distribution which will be
  downloaded, unpacked and tested:
  
+----
mvn clean test -Prun-its -DmavenVersion=2.2.1
+----
  
  To run the ITs using embedded Maven 3.x, additionally activate the <<<embedded>>> profile.
  
  ITs that don't require to fork Maven can also be run from the IDE using the Maven projects from the workspace if the
  Maven dependencies are added to the test class path.
  
  If you're behind a proxy, use the system properties <<<proxy.host>>>, <<<proxy.port>>>, <<<proxy.user>>>, <<<proxy.pass>>>
  and <<<proxy.nonProxyHosts>>> to specify the required proxy setup for the ITs. Alternatively, set the system property
  <<<maven.it.central>>> to a URL of a local repository manager (anonymous authentication only) that proxies the required
  artifacts.


* Core ITs Suite Results

  ITs results are displayed on the console and can be published in the site through Surefire Report.

+----
mvn -Preporting site
+----

  Currently deployed {{{./surefire-report.html}Surefire Report}} was generated with following environment:

%{snippet|file=${project.build.directory}/info.txt}


* Core ITs and dependencies

 A good IT does not depend on external repos like Central, it uses dedicated test plugins and test repositories.
 The {{{https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources-filtered/settings.xml}default <<<settings.xml>>>}}
 used by ITs helps to enforce this by pointing <<<central>>> at <<<file:target/null>>>,
 which obviously can't resolve anything. This setup using a file-based dummy repo also helps execution time,
 because this repo produces (expected) <<<404>>>s much faster than a HTTP-based repo.

 The one place where access to Central is desired is in the <<<MavenITBootstrapTest>>>
 ({{{./xref-test/org/apache/maven/it/MavenITBootstrapTest.html}src}},
 {{{./testapidocs/org/apache/maven/it/MavenITBootstrapTest.html}javadoc}}),
 which doesn't really test anything but just primes the local repo with any artifacts the ITs will need:
 you can see {{{./bootstrap.html}here}} the list of plugins and artifacts that are fetched during bootstrap.

 So some care needs to be taken when introducing new dependencies into the ITs themselves or {{{../core-it-support/}the support plugins}}.
 Many times the failures that we encounter are discrepancies between actual artifact consumption required and
 what is populated during bootstrapping. When forgetting, typical failures (as seen in ASF CI) will give following traces in log:

-------
[INFO] Downloading from central: file:target/null/...
...
[ERROR] Failed to execute goal ... (...) on project ...: ... Could not find artifact ... in central (file:target/null) -> [Help 1]
-------