You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by hb...@apache.org on 2010/01/02 15:12:05 UTC
svn commit: r895201 - in /maven/site/trunk/src/site/apt:
guides/mini/guide-using-toolchains.apt plugin-developers/common-bugs.apt
plugin-developers/plugin-documenting.apt plugin-developers/plugin-testing.apt
Author: hboutemy
Date: Sat Jan 2 14:12:03 2010
New Revision: 895201
URL: http://svn.apache.org/viewvc?rev=895201&view=rev
Log:
changed docs.codehaus.org:MAVEN links to cwiki.apache.org:MAVENOLD
Modified:
maven/site/trunk/src/site/apt/guides/mini/guide-using-toolchains.apt
maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt
maven/site/trunk/src/site/apt/plugin-developers/plugin-documenting.apt
maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt
Modified: maven/site/trunk/src/site/apt/guides/mini/guide-using-toolchains.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/mini/guide-using-toolchains.apt?rev=895201&r1=895200&r2=895201&view=diff
==============================================================================
--- maven/site/trunk/src/site/apt/guides/mini/guide-using-toolchains.apt (original)
+++ maven/site/trunk/src/site/apt/guides/mini/guide-using-toolchains.apt Sat Jan 2 14:12:03 2010
@@ -36,7 +36,7 @@
from the one Maven is running with. (Think how JDK versions can be set in IDEs like Idea, Netbeans and Eclipse)
Toolchains would only work in Maven 2.0.9 and higher versions. For more details about it's design and implementation,
- please see {{{http://docs.codehaus.org/display/MAVEN/Toolchains}Toolchains}}.
+ please see {{{http://cwiki.apache.org/confluence/display/MAVENOLD/Toolchains}Toolchains}}.
Below are the plugins which are toolchain-aware, meaning they can be used with toolchains. Please note that these are
still SNAPSHOT versions and are not yet released.
Modified: maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt?rev=895201&r1=895200&r2=895201&view=diff
==============================================================================
--- maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt (original)
+++ maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt Sat Jan 2 14:12:03 2010
@@ -83,10 +83,10 @@
To save the user from configuring each plugin individually, conventions have been established that allow a user to
centrally configure the file encoding per POM. Plugin developers should respect these conventions whereever possible:
-
+
* {{{http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding}Source File Encoding}}
-
- * {{{http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration}Report Output Encoding}}
+
+ * {{{http://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration}Report Output Encoding}}
[]
@@ -128,7 +128,7 @@
> /C:/temp/foo%20bar+foo
System.out.println( URLDecoder.decode( url.getPath(), "UTF-8" ) );
-> /C:/temp/foo bar foo
+> /C:/temp/foo bar foo
+---
First of all, please note that
@@ -180,12 +180,12 @@
The remaining source of frustration is the conversion from <<<URL>>> to <<<URI>>>. As already said, the <<<URL>>>
class accepts malformed URLs which will make the constructor of <<<URI>>> throw an exception. And indeed, class
loaders from Sun JREs up to Java 1.4 will deliver malformed URLs when queried for a resource. Likewise, the class
- loaders employed by Maven 2.x deliver malformed resource URLs regardless of the JRE version (see
+ loaders employed by Maven 2.x deliver malformed resource URLs regardless of the JRE version (see
{{{http://jira.codehaus.org/browse/MNG-3607}MNG-3607}}).
For all these reasons, it is recommended to use
<<<{{{http://commons.apache.org/io/api-release/org/apache/commons/io/FileUtils.html#toFile(java.net.URL)}FileUtils.toFile()}}>>>
- from Commons IO or
+ from Commons IO or
<<<{{{http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/FileUtils.html#toFile(java.net.URL)}FileUtils.toFile()}}>>>
from a recent Plexus Utilities.
@@ -231,7 +231,7 @@
is provided as the fallback/default language in the base resource bundle. Due to the lookup strategy performed by
<<<{{{http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader)}ResourceBundle.getBundle()}}>>>,
one must always provide a dedicated resource bundle for this default language, too. This bundle should be empty
- because it inherits the strings via the parent chain from the base bundle, but it must exist.
+ because it inherits the strings via the parent chain from the base bundle, but it must exist.
The following example illustrates this requirement. Imagine the broken resource bundle family shown below which is
intended to provide localization for English, German and French:
@@ -375,7 +375,7 @@
Many Maven plugins can get this resolution automatically if they declare their affected mojo parameters of type
<<<java.io.File>>> instead of <<<java.lang.String>>>. This subtle difference in parameter types will trigger a
feature known as <path translation>, i.e. the Maven core will automatically resolve relative paths when it pumps the
- XML configuration into a mojo.
+ XML configuration into a mojo.
* {Determining the Output Directory for a Site Report}
@@ -421,7 +421,7 @@
controlled. In the first case, the parameter <<<outputDirectory>>> from the mojo itself is used. In the second case
however, the Maven Site Plugin takes over control and will set the output directory according to its own configuration
by calling <<<MavenReport.setReportOutputDirectory()>>> on the reports being generated.
-
+
Therefore, developers should always use <<<MavenReport.getReportOutputDirectory()>>> if they need to query the
effective output directory for the report. The implementation of <<<AbstractMavenReport.getOutputDirectory()>>>
is only intended as a fallback in case the mojo is not run as part of the site generation.
@@ -463,7 +463,7 @@
is shared with the plugin class realm. This effectively prevented plugins from using another/newer version of
<<<plexus-utils>>>. This has been solved starting with Maven 2.0.6 by shading (most of) the classes from
<<<plexus-utils>>> (see {{{http://jira.codehaus.org/browse/MNG-2892}MNG-2892}}).
-
+
In short, plugins that strictly require a newer version of <<<plexus-utils>>> also require Maven 2.0.6 as a minimum.
Hence, a POM snippet for a Maven plugin like shown below is misleading:
@@ -481,7 +481,7 @@
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<version>1.5.6</version>
- </dependency>
+ </dependency>
</dependencies>
...
</project>
Modified: maven/site/trunk/src/site/apt/plugin-developers/plugin-documenting.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/plugin-developers/plugin-documenting.apt?rev=895201&r1=895200&r2=895201&view=diff
==============================================================================
--- maven/site/trunk/src/site/apt/plugin-developers/plugin-documenting.apt (original)
+++ maven/site/trunk/src/site/apt/plugin-developers/plugin-documenting.apt Sat Jan 2 14:12:03 2010
@@ -43,4 +43,4 @@
References
- * {{{http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation}Maven Plugin Documentation}}
+ * {{{http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Documentation}Maven Plugin Documentation}}
Modified: maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt?rev=895201&r1=895200&r2=895201&view=diff
==============================================================================
--- maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt (original)
+++ maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt Sat Jan 2 14:12:03 2010
@@ -107,7 +107,7 @@
}
+-----+
- For more information, please refer to {{{http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Harness}Maven Plugin Harness Wiki}}
+ For more information, please refer to {{{http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Harness}Maven Plugin Harness Wiki}}
Integration/Functional testing
@@ -115,7 +115,7 @@
maven-verifier tests are run using JUnit or TestNG, and provide a simple class allowing you to launch Maven and assert on its log file and built artifacts. It also provides a ResourceExtractor, which extracts a Maven project from your src/test/resources directory into a temporary working directory where you can do tricky stuff with it.
- Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to {{{http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test}Creating a Maven Integration Test}}.
+ Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to {{{http://cwiki.apache.org/confluence/display/MAVENOLD/Creating+a+Maven+Integration+Test}Creating a Maven Integration Test}}.
+-----+
public class TrivialMavenVerifierTest extends TestCase