fixed links

git-svn-id: https://svn.apache.org/repos/asf/maven/plugin-testing/trunk@1340844 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt b/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt
index ff4fca1..b3b7388 100644
--- a/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt
+++ b/maven-plugin-testing-harness/src/site/apt/examples/repositories.apt
@@ -100,7 +100,7 @@
     /** {@inheritDoc} */
     public List getRemoteArtifactRepositories()
     {
-        ArtifactRepository repository = new DefaultArtifactRepository( "central", "http://repo1.maven.org/maven2",
+        ArtifactRepository repository = new DefaultArtifactRepository( "central", "http://repo.maven.apache.org/maven2",
                                                                        new DefaultRepositoryLayout() );
 
         return Collections.singletonList( repository );
diff --git a/maven-plugin-testing-harness/src/site/apt/index.apt b/maven-plugin-testing-harness/src/site/apt/index.apt
index 89f8826..bbdca2f 100644
--- a/maven-plugin-testing-harness/src/site/apt/index.apt
+++ b/maven-plugin-testing-harness/src/site/apt/index.apt
@@ -29,18 +29,18 @@
  {{{http://plexus.codehaus.org}Plexus}} components, providing stub objects for Maven functionality such as projects,
  and populating fields from an XML file that resembles the plugin configuration in the POM.
 
- The best way to start is to read the cookbook {{{getting-started/index.html}How to use Maven Plugin Testing Harness}}.
+ The best way to start is to read the cookbook {{{./getting-started/index.html}How to use Maven Plugin Testing Harness}}.
 
 * Examples
 
    The following examples shows how to use the Testing Harness in more advanced usecases:
 
-   * {{{examples/complex-mojo-parameters.html}Testing Complex Mojo Parameters}}
+   * {{{./examples/complex-mojo-parameters.html}Testing Complex Mojo Parameters}}
 
-   * {{{examples/multiproject.html}Testing Multiproject}}
+   * {{{./examples/multiproject.html}Testing Multiproject}}
 
-   * {{{examples/repositories.html}Testing Using Repositories}}
+   * {{{./examples/repositories.html}Testing Using Repositories}}
 
-   * {{{examples/artifact.html}Testing Project Artifact}}
+   * {{{./examples/artifact.html}Testing Project Artifact}}
 
    []
diff --git a/maven-plugin-testing-harness/src/site/fml/faq.fml b/maven-plugin-testing-harness/src/site/fml/faq.fml
index b31b5e7..9239312 100644
--- a/maven-plugin-testing-harness/src/site/fml/faq.fml
+++ b/maven-plugin-testing-harness/src/site/fml/faq.fml
@@ -46,8 +46,8 @@
               the same way you'd write any other JUnit test cases, i.e. by writing a test class which extends
               <i>TestCase</i>.</dd>
             <dt>TestCase from Plexus</dt>
-            <dd>Mojos are written to take specific advantage of the <a href="http://plexus.codehaus.org/">Plexus</a>
-              container. If you need Plexus container services, you could write your class which extends <i>PlexusTestCase</i>,
+            <dd>Mojos are written to take specific advantage of the <a href="http://plexus.codehaus.org/plexus-containers/">Plexus
+              container</a>. If you need Plexus container services, you could write your class which extends <i>PlexusTestCase</i>,
               instead of <i>TestCase</i>.</dd>
             <dt>TestCase from Testing Harness</dt>
             <dd>If you need to inject Maven objects into your mojo, you could use the <i>maven-plugin-testing-harness</i>.
diff --git a/maven-plugin-testing-tools/src/site/apt/index.apt b/maven-plugin-testing-tools/src/site/apt/index.apt
index c6cbfca..4d3568e 100644
--- a/maven-plugin-testing-tools/src/site/apt/index.apt
+++ b/maven-plugin-testing-tools/src/site/apt/index.apt
@@ -36,7 +36,7 @@
   (possibly after resolving them from a remote repository). Because of this, the only practical way 
   to use the current plugin within an integration-test build is to install it into some sort of local 
   repository, then direct Maven to use that local repository for the build. To avoid side effects in
-  other builds (remember, we're building Maven plugins here...and they're used to build other projects),
+  other builds (remember, we're building Maven plugins here... and they're used to build other projects),
   it's critical to avoid using the main local repository used for normal Maven builds. Therefore,
   plugin integration tests require a custom local repository, to which the integration-testing builds
   can be directed. Further complicating this testing scenario is the fact that the plugin's parent
@@ -96,7 +96,7 @@
     
 * Utilities Included in this Library
 
-  For more information on the APIs described below, see the {{{apidocs/index.html}JavaDocs}}.
+  For more information on the APIs described below, see the {{{./apidocs/index.html}JavaDocs}}.
 
   * <<PluginTestTool>> - The main entry point for setting up the plugin-testing environment, this
     utility orchestrates the ProjectTool, RepositoryTool, and BuildTool in order to produce a local