http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/include.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/include.adoc b/asciidoc/settings/include.adoc
index bc66575..faf468e 100644
--- a/asciidoc/settings/include.adoc
+++ b/asciidoc/settings/include.adoc
@@ -85,5 +85,5 @@ The included Ivy settings defines a resolver named default, 
which is an ivyrep r
 
 ----
 
-with ivysettings-macro.xml being the Ivy settings example given on the 
link:../settings/macrodef.html[macrodef documentation page].
+with ivysettings-macro.xml being the Ivy settings example given on the 
link:../settings/macrodef{outfilesuffix}[macrodef documentation page].
 This lets us easily reuse the custom macro resolver.

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/latest-strategies.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/latest-strategies.adoc 
b/asciidoc/settings/latest-strategies.adoc
index 20e2746..d4c756e 100644
--- a/asciidoc/settings/latest-strategies.adoc
+++ b/asciidoc/settings/latest-strategies.adoc
@@ -21,7 +21,7 @@
 
 *Tag:* latest-strategies
 
-[ivysettings.latest-strategies]#Defines a list of 
link:../concept.html#latest[latest strategies] usable in Ivy.# Each latest 
strategy is identified by its name, given as an attribute.
+[ivysettings.latest-strategies]#Defines a list of 
link:../concept{outfilesuffix}#latest[latest strategies] usable in Ivy.# Each 
latest strategy is identified by its name, given as an attribute.
 
 The child tag used for the latest strategy must be equal to a name of a latest 
strategy type (usually added with the `typedef` tag).
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/macrodef.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/macrodef.adoc b/asciidoc/settings/macrodef.adoc
index 868b1b2..0d6bf6f 100644
--- a/asciidoc/settings/macrodef.adoc
+++ b/asciidoc/settings/macrodef.adoc
@@ -27,7 +27,7 @@
 
 This task eases the process of creating a new dependency resolver, because it 
avoids writing Java code.
 
-It is generally used in combination with the 
link:../settings/include.html[include] feature to help reuse a macro in 
multiple settings files.
+It is generally used in combination with the 
link:../settings/include{outfilesuffix}[include] feature to help reuse a macro 
in multiple settings files.
 
 A macro is defined by declaring an existing resolver within it. Then you can 
use attributes to pass parameters to the newly defined resolver type. 
Attributes are defined with a name, and optionally a default value, and are 
used using the following syntax:
 
@@ -109,7 +109,7 @@ This is equivalent to:
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../settings/macrodef/attribute.html[attribute]|defines an attribute for 
the macro resolver|0..n
+|link:../settings/macrodef/attribute{outfilesuffix}[attribute]|defines an 
attribute for the macro resolver|0..n
 |any resolver|defines the base resolver upon which this macro is defined|1
 |=======
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/macrodef/attribute.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/macrodef/attribute.adoc 
b/asciidoc/settings/macrodef/attribute.adoc
index 8f31525..251d904 100644
--- a/asciidoc/settings/macrodef/attribute.adoc
+++ b/asciidoc/settings/macrodef/attribute.adoc
@@ -21,7 +21,7 @@
 
 *Tag:* attribute
 
-[ivysettings.macrodef.attribute]#Defines a macrodef attribute.# See 
link:../macrodef.html[macrodef] for details.
+[ivysettings.macrodef.attribute]#Defines a macrodef attribute.# See 
link:../macrodef{outfilesuffix}[macrodef] for details.
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/module.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/module.adoc b/asciidoc/settings/module.adoc
index 1eda86e..903fcaa 100644
--- a/asciidoc/settings/module.adoc
+++ b/asciidoc/settings/module.adoc
@@ -30,13 +30,13 @@ It also gives the specific setting to use for this module 
set.
 For each module set, you can configure:
 
 
-    * the link:../settings/resolvers.html[resolver] to use +
+    * the link:../settings/resolvers{outfilesuffix}[resolver] to use +
 
-    * the link:../settings/conflict-managers.html[conflict manager] to use +
+    * the link:../settings/conflict-managers{outfilesuffix}[conflict manager] 
to use +
 
-    * the default link:../terminology.html#branch[branch] to use +
+    * the default link:../terminology{outfilesuffix}#branch[branch] to use +
 
-    * the link:../use/resolve.html[resolve mode] to use +
+    * the link:../use/resolve{outfilesuffix}[resolve mode] to use +
 
 
 
@@ -50,7 +50,7 @@ For each module set, you can configure:
 |name|the module's name to match to apply the rule.|No, defaults to *
 |revision|the module's revision to match to apply the rule. Note that the 
version may not be resolved yet (be `latest.integration`, for instance), so be 
very careful when using this attribute (*__since 2.0__*).|No, defaults to *
 |_any extra attribute_|an extra attribute to match to apply the rule (*__since 
2.0__*).|No, defaults to *
-|matcher|the link:../concept.html#matcher[matcher] to use to match the modules 
to which the resolver should be applied (*__since 1.3__*).|No, defaults to 
exactOrRegexp
+|matcher|the link:../concept{outfilesuffix}#matcher[matcher] to use to match 
the modules to which the resolver should be applied (*__since 1.3__*).|No, 
defaults to exactOrRegexp
 |resolver|the name of the resolver to apply. The resolver must have been 
defined in the resolvers section of the settings file.|No
 |conflict-manager|the name of the conflict manager to apply (*__since 
1.4__*).|No
 |branch|the default branch to apply (*__since 1.4__*).|No

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/modules.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/modules.adoc b/asciidoc/settings/modules.adoc
index b0ca575..f030d33 100644
--- a/asciidoc/settings/modules.adoc
+++ b/asciidoc/settings/modules.adoc
@@ -36,5 +36,5 @@ NOTE: You can greatly improve the performance of dependency 
resolution by config
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../settings/module.html[module]|defines a module set rule|1..n
+|link:../settings/module{outfilesuffix}[module]|defines a module set rule|1..n
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/namespace.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/namespace.adoc b/asciidoc/settings/namespace.adoc
index 68a59a8..41f4dc1 100644
--- a/asciidoc/settings/namespace.adoc
+++ b/asciidoc/settings/namespace.adoc
@@ -19,9 +19,9 @@
 
 *Tag:* namespace
 
-[ivysettings.namespaces.namespace]#Defines a new namespace. A namespace is 
identified by a name, which can be referenced by one of the 
link:../settings/resolvers.html[resolvers].#
+[ivysettings.namespaces.namespace]#Defines a new namespace. A namespace is 
identified by a name, which can be referenced by one of the 
link:../settings/resolvers{outfilesuffix}[resolvers].#
 
-An overview of namespaces is given in the 
link:../settings/namespaces.html[namespaces] documentation.
+An overview of namespaces is given in the 
link:../settings/namespaces{outfilesuffix}[namespaces] documentation.
 
 A namespace mainly consists of a list of rules, each rule defining a 
translation between a system namespace and the defined namespace, and vice 
versa.
 
@@ -44,7 +44,7 @@ There are two main possibilities for using these rules. By 
default, a namespace
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../settings/namespace/rule.html[rule]|defines a new namespace rule|0..n
+|link:../settings/namespace/rule{outfilesuffix}[rule]|defines a new namespace 
rule|0..n
 |=======
 
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/namespace/fromtosystem.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/namespace/fromtosystem.adoc 
b/asciidoc/settings/namespace/fromtosystem.adoc
index 93e4dd4..9cf364d 100644
--- a/asciidoc/settings/namespace/fromtosystem.adoc
+++ b/asciidoc/settings/namespace/fromtosystem.adoc
@@ -29,6 +29,6 @@
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../../settings/namespace/src.html[src]|defines a source name which can 
be accepted|1..n
-|link:../../settings/namespace/dest.html[dest]|defines the translation to 
apply when a name is accepted by an src pattern|1
+|link:../../settings/namespace/src{outfilesuffix}[src]|defines a source name 
which can be accepted|1..n
+|link:../../settings/namespace/dest{outfilesuffix}[dest]|defines the 
translation to apply when a name is accepted by an src pattern|1
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/namespace/rule.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/namespace/rule.adoc 
b/asciidoc/settings/namespace/rule.adoc
index 425e36e..a4cc225 100644
--- a/asciidoc/settings/namespace/rule.adoc
+++ b/asciidoc/settings/namespace/rule.adoc
@@ -23,7 +23,7 @@
 
 [ivysettings.namespaces.namespace.rule]#Defines a new namespace rule.# A rule 
defines a translation between system namespace and the defined namespace, and 
vice versa.
 
-See the link:../../settings/namespace.html[namespace] doc for details.
+See the link:../../settings/namespace{outfilesuffix}[namespace] doc for 
details.
 
 
 == Child elements
@@ -32,6 +32,6 @@ See the link:../../settings/namespace.html[namespace] doc for 
details.
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../../settings/namespace/fromtosystem.html[fromsystem]|defines the 
translation to apply from the system namespace to the defined namespace|1
-|link:../../settings/namespace/fromtosystem.html[tosystem]|defines the 
translation to apply from the defined namespace to the system namespace|1
+|link:../../settings/namespace/fromtosystem{outfilesuffix}[fromsystem]|defines 
the translation to apply from the system namespace to the defined namespace|1
+|link:../../settings/namespace/fromtosystem{outfilesuffix}[tosystem]|defines 
the translation to apply from the defined namespace to the system namespace|1
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/namespaces.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/namespaces.adoc 
b/asciidoc/settings/namespaces.adoc
index b49c105..c951dc3 100644
--- a/asciidoc/settings/namespaces.adoc
+++ b/asciidoc/settings/namespaces.adoc
@@ -43,5 +43,5 @@ This very powerful feature is thoroughly used in the 
link:../tutorial/build-repo
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../settings/namespace.html[namespace]|defines a new namespace|0..n
+|link:../settings/namespace{outfilesuffix}[namespace]|defines a new 
namespace|0..n
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/outputters.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/outputters.adoc 
b/asciidoc/settings/outputters.adoc
index 8b9f3f9..a41cb11 100644
--- a/asciidoc/settings/outputters.adoc
+++ b/asciidoc/settings/outputters.adoc
@@ -45,12 +45,12 @@ Two report outputters are registered by default:
 
 
     * an xml report outputter 
(link:https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=src/java/org/apache/ivy/plugins/report/XmlReportOutputter.java[XmlReportOutputter])
 +
-    which produces an XML report in the cache, which is mandatory for correct 
Ivy behaviour, since it's that report which is used when you do a post resolve 
step in a separate build from the resolve itself. It's also this XML report 
which is processed to generate all the different reports available in the 
link:../use/report.html[report] task.
+    which produces an XML report in the cache, which is mandatory for correct 
Ivy behaviour, since it's that report which is used when you do a post resolve 
step in a separate build from the resolve itself. It's also this XML report 
which is processed to generate all the different reports available in the 
link:../use/report{outfilesuffix}[report] task.
 
 
 The child tag used for the parser must be equal to a name of a report 
outputter type (added with the `typedef` tag).
 
-To see how to define your own report outputter see 
link:../extend.html[Extending Ivy documentation]
+To see how to define your own report outputter see 
link:../extend{outfilesuffix}[Extending Ivy documentation]
 
 
 == Child elements

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/settings.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/settings.adoc b/asciidoc/settings/settings.adoc
index e98950d..32bfd43 100644
--- a/asciidoc/settings/settings.adoc
+++ b/asciidoc/settings/settings.adoc
@@ -23,7 +23,7 @@
 
 [ivysettings.settings]#Configures some important Ivy behaviour: default 
resolver, latest strategy, conflict manager and some others.#
 
-The default resolver is used whenever nothing else is configured in the 
modules section of the settings file. It should give the name of a dependency 
resolver defined in the link:../settings/resolvers.html[resolvers] section of 
the settings file.
+The default resolver is used whenever nothing else is configured in the 
modules section of the settings file. It should give the name of a dependency 
resolver defined in the link:../settings/resolvers{outfilesuffix}[resolvers] 
section of the settings file.
 
 The default latest strategy and conflict manager can also be configured here.
 
@@ -44,18 +44,18 @@ So if there is a setting in the resolver, it always wins 
against all other setti
 |defaultResolver|the name of the default resolver to use|No, but all modules 
should be configured in the modules section if not provided
 |defaultLatestStrategy|the name of the default latest strategy to use|No, 
defaults to latest-revision
 |defaultConflictManager|the name of the default conflict manager to use|No, 
defaults to latest-revision
-|defaultBranch|the default branch to use for all modules, except if they have 
a link:../settings/module.html[module specific branch setting]. (*__since 
1.4__*)|No, defaults to no default branch
-|defaultResolveMode|the default link:../use/resolve.html[resolve mode] to use 
for all modules, except if they have a link:../settings/module.html[module 
specific resolve mode setting]. (*__since 2.0__*)|No, defaults to 'default'
-|[[circularDependencyStrategy]]circularDependencyStrategy|the name of the 
link:../concept.html#circular[circular dependency strategy] to use (*__since 
1.4__*)|No, defaults to warn
+|defaultBranch|the default branch to use for all modules, except if they have 
a link:../settings/module{outfilesuffix}[module specific branch setting]. 
(*__since 1.4__*)|No, defaults to no default branch
+|defaultResolveMode|the default link:../use/resolve{outfilesuffix}[resolve 
mode] to use for all modules, except if they have a 
link:../settings/module{outfilesuffix}[module specific resolve mode setting]. 
(*__since 2.0__*)|No, defaults to 'default'
+|[[circularDependencyStrategy]]circularDependencyStrategy|the name of the 
link:../concept{outfilesuffix}#circular[circular dependency strategy] to use 
(*__since 1.4__*)|No, defaults to warn
 |validate|Indicates if Ivy files should be validated against ivy.xsd or 
not.|No, defaults to true
 |useRemoteConfig|true to configure ivyrep and ibiblio resolver from a remote 
settings file (updated with changes in those repository structure if any) 
(*__since 1.2__*)|No, defaults to false
 |httpRequestMethod|specifies the HTTP method to use to retrieve information 
about an URL. Possible values are 'GET' and 'HEAD'. This setting can be used to 
solve problems with firewalls and proxies. (*__since 2.0__*)|No, defaults to 
'HEAD'
 |[line-through]#defaultCache#|a path to a directory to use as default basedir 
for both resolution and repository cache(s). +
-__Deprecated, we recommend using defaultCacheDir on the 
link:../settings/caches.html[caches] tag instead__|No, defaults to .ivy2/cache 
in user home
+__Deprecated, we recommend using defaultCacheDir on the 
link:../settings/caches{outfilesuffix}[caches] tag instead__|No, defaults to 
.ivy2/cache in user home
 |[line-through]#checkUpToDate#|Indicates if date should be checked before 
retrieving artifacts from cache. +
-__Deprecated, we recommend using overwriteMode on the 
link:../use/retrieve.html[retrieve] task instead__|No, defaults to true
+__Deprecated, we recommend using overwriteMode on the 
link:../use/retrieve{outfilesuffix}[retrieve] task instead__|No, defaults to 
true
 |[line-through]#cacheIvyPattern#|a pattern to indicate where Ivy files should 
be put in cache. +
-__Deprecated, we recommend using ivyPattern on the 
link:../settings/caches.html[caches] tag instead__|No, defaults to 
[organisation]/[module]/ivy-[revision].xml
+__Deprecated, we recommend using ivyPattern on the 
link:../settings/caches{outfilesuffix}[caches] tag instead__|No, defaults to 
[organisation]/[module]/ivy-[revision].xml
 |[line-through]#cacheArtifactPattern#|a pattern to indicate where artifact 
files should be put in cache. +
-__Deprecated, we recommend using artifactPattern on the 
link:../settings/caches.html[caches] tag instead__|No, defaults to 
[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
+__Deprecated, we recommend using artifactPattern on the 
link:../settings/caches{outfilesuffix}[caches] tag instead__|No, defaults to 
[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/status.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/status.adoc b/asciidoc/settings/status.adoc
index 4d73969..29442da 100644
--- a/asciidoc/settings/status.adoc
+++ b/asciidoc/settings/status.adoc
@@ -23,7 +23,7 @@
 
 [ivysettings.statuses.status]#Define one available module status.#
 
-See link:../settings/statuses.html[statuses] page for details about how 
statuses are defined.
+See link:../settings/statuses{outfilesuffix}[statuses] page for details about 
how statuses are defined.
 
 
 == Attributes

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/statuses.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/statuses.adoc b/asciidoc/settings/statuses.adoc
index 290a65d..46c3cf8 100644
--- a/asciidoc/settings/statuses.adoc
+++ b/asciidoc/settings/statuses.adoc
@@ -50,7 +50,7 @@ NOTE: The statuses order is important, the first is 
considered the more mature,
 [options="header"]
 |=======
 |Element|Description|Cardinality
-|link:../settings/status.html[status]|defines a new status|0..n
+|link:../settings/status{outfilesuffix}[status]|defines a new status|0..n
 |=======
 
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/timeout-constraints.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/timeout-constraints.adoc 
b/asciidoc/settings/timeout-constraints.adoc
index 654321c..5af7ec3 100644
--- a/asciidoc/settings/timeout-constraints.adoc
+++ b/asciidoc/settings/timeout-constraints.adoc
@@ -21,7 +21,7 @@
 
 [*__since 2.5__*]
 
-Ivy, internally, communicates with various remote systems for dealing with 
module descriptors and artifacts. This is done through various 
link:../concept.html[dependency resolvers] that are configured in the Ivy 
settings. This communication typically involves opening a connection to the 
target system and reading content from those systems. As with all remote 
communication, certain systems can sometimes be slow or even unavailable on 
some occasions. [ivysettings.timeout-constraints]#`timeout-constraints` in Ivy 
settings allows you to configure timeouts that can then be used by Ivy while 
communicating with remote systems.#
+Ivy, internally, communicates with various remote systems for dealing with 
module descriptors and artifacts. This is done through various 
link:../concept{outfilesuffix}[dependency resolvers] that are configured in the 
Ivy settings. This communication typically involves opening a connection to the 
target system and reading content from those systems. As with all remote 
communication, certain systems can sometimes be slow or even unavailable on 
some occasions. [ivysettings.timeout-constraints]#`timeout-constraints` in Ivy 
settings allows you to configure timeouts that can then be used by Ivy while 
communicating with remote systems.#
 
 NOTE: Although, timeouts are most likely to be used by dependency resolvers, 
the setting up of timeouts through the use of `timeout-constraints` doesn't 
really bother about where those timeouts are used. As such, it's _not_ an error 
to have `timeout-constraints` within a Ivy settings file which may never be 
referred to by any resolver.
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/triggers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/triggers.adoc b/asciidoc/settings/triggers.adoc
index 23e7697..5f87277 100644
--- a/asciidoc/settings/triggers.adoc
+++ b/asciidoc/settings/triggers.adoc
@@ -39,7 +39,7 @@ Ivy supports 3 type of triggers out of the box:
      echo a message, usually in a file
 
 
-If you want to use a different trigger, you can link:../extend.html[implement 
your own].
+If you want to use a different trigger, you can 
link:../extend{outfilesuffix}[implement your own].
 
 The following events are available in Ivy:
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/typedef.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/typedef.adoc b/asciidoc/settings/typedef.adoc
index fd3dfa5..006e40b 100644
--- a/asciidoc/settings/typedef.adoc
+++ b/asciidoc/settings/typedef.adoc
@@ -22,7 +22,7 @@
 *Tag:* typedef
 
 [ivysettings.typedef]#Defines a new type in Ivy. Useful to define new 
dependency resolvers, in particular, but also latest strategies.#
-See link:../extend.html[how to write and plug your own dependency resolver] 
for details.
+See link:../extend{outfilesuffix}[how to write and plug your own dependency 
resolver] for details.
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/settings/version-matchers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/settings/version-matchers.adoc 
b/asciidoc/settings/version-matchers.adoc
index 9eba6fb..56ba2c7 100644
--- a/asciidoc/settings/version-matchers.adoc
+++ b/asciidoc/settings/version-matchers.adoc
@@ -76,7 +76,7 @@ A matcher that matches all revisions starting with a specific 
prefix. The syntax
 === Latest (Status) Matcher
 
 
-A matcher that matches versions based on their status. The predefined statuses 
in Ivy are `release`, `milestone` and `integration`. It's possible to define 
your own statuses, see link:../settings/statuses.html[statuses] for more 
details.
+A matcher that matches versions based on their status. The predefined statuses 
in Ivy are `release`, `milestone` and `integration`. It's possible to define 
your own statuses, see link:../settings/statuses{outfilesuffix}[statuses] for 
more details.
 
 
 [options="header"]
@@ -150,7 +150,7 @@ Matcher types may be one of "regexp", "exact", "glob", or 
"exactOrRegexp".  Glob
 
 Maven has the notion of timestamped snapshots, which essentially are snapshot 
versions of a particular Maven artifact, but have a specific timestamp 
associated with them so that the snapshot revision (which by nature are 
changing over time), can be traced back to the exact artifacts. Maven allows 
other artifacts to depend on such timestamped snapshots.
 
-Ivy too allows such timestamped dependencies to be part of the module's 
dependencies. For such dependencies to be properly parsed and resolved, a 
`maven-tsnap-vm` version matcher needs to be configured in the Ivy settings and 
link:../resolver/ibiblio.html[ibiblio resolver] must be one of the resolvers 
that are used for dependency resolution.
+Ivy too allows such timestamped dependencies to be part of the module's 
dependencies. For such dependencies to be properly parsed and resolved, a 
`maven-tsnap-vm` version matcher needs to be configured in the Ivy settings and 
link:../resolver/ibiblio{outfilesuffix}[ibiblio resolver] must be one of the 
resolvers that are used for dependency resolution.
 
 NOTE: Maven has a specific syntax for timestamped snapshot versions and only 
such versions are understood by Ivy.
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/build-repository.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/build-repository.adoc 
b/asciidoc/tutorial/build-repository.adoc
index 05debf3..a86ce12 100644
--- a/asciidoc/tutorial/build-repository.adoc
+++ b/asciidoc/tutorial/build-repository.adoc
@@ -17,11 +17,11 @@
    under the License.
 ////
 
-The link:../use/install.html[install] Ant task lets you copy a module or a set 
of modules from one repository to another. This is very useful to build and 
maintain an enterprise or team repository. If you don't want to give access to 
the public Maven 2 repository to the developers on your team (to keep control 
over which modules are in use in your company or your team, for instance), it 
can sometimes become tiresome to answer the developers request to add new 
modules or new versions by hand.
+The link:../use/install{outfilesuffix}[install] Ant task lets you copy a 
module or a set of modules from one repository to another. This is very useful 
to build and maintain an enterprise or team repository. If you don't want to 
give access to the public Maven 2 repository to the developers on your team (to 
keep control over which modules are in use in your company or your team, for 
instance), it can sometimes become tiresome to answer the developers request to 
add new modules or new versions by hand.
 
-Fortunately the link:../use/install.html[install] task is here to help: you 
can use specific settings for your repository maintenance build which will be 
used to maintain your target enterprise repository. These settings will point 
to another repository (for instance, the Maven 2 public repository) so that you 
will just have to ask Ivy to install the modules you want with a simple command 
line.
+Fortunately the link:../use/install{outfilesuffix}[install] task is here to 
help: you can use specific settings for your repository maintenance build which 
will be used to maintain your target enterprise repository. These settings will 
point to another repository (for instance, the Maven 2 public repository) so 
that you will just have to ask Ivy to install the modules you want with a 
simple command line.
 
-To demonstrate this, we will first use a basic Ivy settings file to show how 
it works, and then we will use the advanced 
link:../settings/namespaces.html[namespaces] features to demonstrate how to 
deal with naming mismatches between the source and target repository.
+To demonstrate this, we will first use a basic Ivy settings file to show how 
it works, and then we will use the advanced 
link:../settings/namespaces{outfilesuffix}[namespaces] features to demonstrate 
how to deal with naming mismatches between the source and target repository.
 
 
 == The project used

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/build-repository/advanced.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/build-repository/advanced.adoc 
b/asciidoc/tutorial/build-repository/advanced.adoc
index ea92142..d2f7168 100644
--- a/asciidoc/tutorial/build-repository/advanced.adoc
+++ b/asciidoc/tutorial/build-repository/advanced.adoc
@@ -28,7 +28,7 @@ We have seen in the previous example, that we could use some 
public repositories
 
 This problem is pretty normal when you have an existing repository, and want 
to benefit from large public repositories which do not follow the same naming 
conventions. It also shows up because many public repositories do not use a  
consistent naming scheme. For example, why don't all the Apache Commons modules 
use the org.apache.commons organization? Well... for historical reasons. But if 
you set up your own repository, you may not want to suffer from the mistakes of 
history.
 
-Fortunately, Ivy has a very powerful answer to this problem: 
link:../../settings/namespaces.html[namespaces].
+Fortunately, Ivy has a very powerful answer to this problem: 
link:../../settings/namespaces{outfilesuffix}[namespaces].
 
 
 == Using namespaces

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/build-repository/basic.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/build-repository/basic.adoc 
b/asciidoc/tutorial/build-repository/basic.adoc
index bf2ca66..5e043e2 100644
--- a/asciidoc/tutorial/build-repository/basic.adoc
+++ b/asciidoc/tutorial/build-repository/basic.adoc
@@ -17,12 +17,12 @@
    under the License.
 ////
 
-In this first step, we use the link:../../use/install.html[install] Ant task 
to install modules from the Maven 2 repository to a file system based 
repository. We first install a module by itself, excluding dependencies, then 
again with its dependencies.
+In this first step, we use the link:../../use/install{outfilesuffix}[install] 
Ant task to install modules from the Maven 2 repository to a file system based 
repository. We first install a module by itself, excluding dependencies, then 
again with its dependencies.
 
 
 == Basic: ivysettings.xml file used
 
-The Ivy settings file that we will use is very simple here. It defines two 
resolvers, __libraries__ and __my-repository__. The first one is used as the 
source, the second one as the destination. In a typical setup, the second one 
would be configured using an link:../../settings/include.html[include] that 
included an existing settings file used by the development team.
+The Ivy settings file that we will use is very simple here. It defines two 
resolvers, __libraries__ and __my-repository__. The first one is used as the 
source, the second one as the destination. In a typical setup, the second one 
would be configured using an 
link:../../settings/include{outfilesuffix}[include] that included an existing 
settings file used by the development team.
 
 
 [source]
@@ -60,7 +60,7 @@ Let's have a look at the _maven2_ target.
 
 ----
 
-Pretty simple, we call the link:../../use/install.html[ivy:install] task with 
the settings we have loaded using link:../../use/settings.html[ivy:settings] as 
usual. We then set the source and destination repositories using the __from__ 
and __to__ attributes. We used Ant properties for these values here, which 
helps ease the maintenance of the script, but it's basically the name of our 
resolvers: 'libraries' for the source and 'my-repository' for the destination.
+Pretty simple, we call the link:../../use/install{outfilesuffix}[ivy:install] 
task with the settings we have loaded using 
link:../../use/settings{outfilesuffix}[ivy:settings] as usual. We then set the 
source and destination repositories using the __from__ and __to__ attributes. 
We used Ant properties for these values here, which helps ease the maintenance 
of the script, but it's basically the name of our resolvers: 'libraries' for 
the source and 'my-repository' for the destination.
 
 Here is the Ant call output :
 
@@ -119,7 +119,7 @@ include::asciidoc/tutorial/log/install-deps.txt[]
 
 As you can see the installation has failed, and if you look at the log you 
will see that there are missing artifacts in the source repository. This means 
that you will need to download those artifacts manually, and copy them to your 
destination repository to complete the installation. Fortunately Ivy uses a 
best effort algorithm during install, so that everything gets installed except 
the missing artifacts. (Note: these missing artifacts are not in the public 
Maven repository due to licensing issues.)
 
-You may also have noticed that Ivy installed 2 different revisions of 
commons-logging (1.0.2, 1.0.4). This is due to the fact that we used the "no 
conflict" link:../../settings/conflict-managers.html[conflict manager] in the 
Ivy settings file.
+You may also have noticed that Ivy installed 2 different revisions of 
commons-logging (1.0.2, 1.0.4). This is due to the fact that we used the "no 
conflict" link:../../settings/conflict-managers{outfilesuffix}[conflict 
manager] in the Ivy settings file.
 
 We do not want to evict any modules because we are building our own 
repository. Indeed, if we get both commons-logging 1.0.2 and 1.0.4, it's 
because some modules among the transitive dependencies of hibernate depend on 
1.0.2 and others on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 
would be inconsistent in your own repository (depending on a version you did 
not install). Thus developers using this module directly would run into a 
problem.
 
@@ -137,4 +137,4 @@ 
include::asciidoc/tutorial/log/myrepository-content-deps.txt[]
 
 As you can see there is no POM here (POM is the module metadata format used by 
Maven 2, available in the Maven 2 repository). Instead you can see there's an 
Ivy file, which is actually the original Hibernate POM converted into an Ivy 
file. So now you have a true Ivy repository with Ivy files, where you can use 
the full power of Ivy if you want to adjust the module metadata (module 
configurations, fine grained exclusions and transitivity control, per module 
conflict manager, ...).
 
-OK, enough for this simple repository installation, the 
link:../../tutorial/build-repository/advanced.html[next tutorial] will show how 
you can deal with more complex cases where your source and destination 
repositories do not follow the same naming conventions.
+OK, enough for this simple repository installation, the 
link:../../tutorial/build-repository/advanced{outfilesuffix}[next tutorial] 
will show how you can deal with more complex cases where your source and 
destination repositories do not follow the same naming conventions.

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/conf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/conf.adoc b/asciidoc/tutorial/conf.adoc
index 247612b..743a072 100644
--- a/asciidoc/tutorial/conf.adoc
+++ b/asciidoc/tutorial/conf.adoc
@@ -21,7 +21,7 @@ This tutorial introduces the use of module configurations in 
Ivy files. Ivy modu
 
 More seriously, configurations in Ivy can be better understood as views on 
your module, and you will see how they can be used effectively here.
 
-Reference documentation on configurations can be found 
link:../terminology.html[here] and link:../ivyfile/configurations.html[here].
+Reference documentation on configurations can be found 
link:../terminology{outfilesuffix}[here] and 
link:../ivyfile/configurations{outfilesuffix}[here].
 
 == Introduction
 
@@ -133,7 +133,7 @@ Now that we have shipped (published) our fantastic filter 
library, we want to us
 
 We create 3 configurations that define the different ways we want to use the 
application. The *build* configuration defines the compile-time dependencies, 
and thus only needs the api conf from the filter-framework project. The other 
two configurations define runtime dependencies. One will only use our 
"home-made" jar, and the other will use an external jar.
 
-We also defined a dependency on our previously built library. In this 
dependency, we use configuration mappings to match ours with the dependency's 
configurations. You can find more information about configuration mapping 
link:../ivyfile/configurations.html[here]
+We also defined a dependency on our previously built library. In this 
dependency, we use configuration mappings to match ours with the dependency's 
configurations. You can find more information about configuration mapping 
link:../ivyfile/configurations{outfilesuffix}[here]
 
 
 . *build->api* : here we tell Ivy that our *build* configuration depends on 
the *api* configuration of the dependency +

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/defaultconf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/defaultconf.adoc 
b/asciidoc/tutorial/defaultconf.adoc
index 4a1b81e..2d19bf5 100644
--- a/asciidoc/tutorial/defaultconf.adoc
+++ b/asciidoc/tutorial/defaultconf.adoc
@@ -21,7 +21,7 @@
 
 Ivy comes bundled with some default settings which makes it pretty simple to 
use in a typical environment. This tutorial, which is close to a reference 
document, explains what those default settings are and how they can be adjusted 
to your needs.
 
-To fully understand the concept of settings and what you can do with them, we 
suggest reading other tutorials related to settings (like 
link:../tutorial/multiple.html[Multiple Resolvers] and 
link:../tutorial/dual.html[Dual Resolver]) or the 
link:../settings.html[Settings Files] reference documentation.
+To fully understand the concept of settings and what you can do with them, we 
suggest reading other tutorials related to settings (like 
link:../tutorial/multiple{outfilesuffix}[Multiple Resolvers] and 
link:../tutorial/dual{outfilesuffix}[Dual Resolver]) or the 
link:../settings{outfilesuffix}[Settings Files] reference documentation.
 
 
 == Concept
@@ -146,7 +146,7 @@ By default, the public repository is ibiblio in m2 
compatible mode (in other wor
 
 This repository has the advantage of providing a lot of modules, with metadata 
for most of them. The quality of metadata is not always perfect, but it's a 
very good start to use a tool like Ivy and benefit from the power of transitive 
dependency management.
 
-Despite its ease of use, we suggest reading the 
link:../bestpractices.html[Best practices] to have a good understanding of the 
pros and cons of using a public unmanaged repository before depending on such a 
repository for your enterprise build system.
+Despite its ease of use, we suggest reading the 
link:../bestpractices{outfilesuffix}[Best practices] to have a good 
understanding of the pros and cons of using a public unmanaged repository 
before depending on such a repository for your enterprise build system.
 
 NOTE: In `1.4` version, Ivy was using `ivyrep` as the default resolver, if you 
want to restore this, set `ivy.14.compatible=true` as an Ant property
 
@@ -289,4 +289,4 @@ Now the last thing you will need in order to properly take 
advantage of the defa
 
 ----
 
-There you go, you should have enough clues to configure Ivy the way you want. 
Check the link:../settings.html[settings documentation] to see if what you want 
to do is possible, and go ahead!
+There you go, you should have enough clues to configure Ivy the way you want. 
Check the link:../settings{outfilesuffix}[settings documentation] to see if 
what you want to do is possible, and go ahead!

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/dependence.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/dependence.adoc 
b/asciidoc/tutorial/dependence.adoc
index 96f174e..18552cd 100644
--- a/asciidoc/tutorial/dependence.adoc
+++ b/asciidoc/tutorial/dependence.adoc
@@ -130,7 +130,7 @@ This tag loads some properties for the Ivy process, just 
like Ant does.
 === settings
 
 This tag initializes some parameters for the Ivy process. In this case, the 
directory that Ivy will use to cache artifacts will be in a sub directory 
called ivy-cache of the directory containing the `ivysettings.xml` file itself.
-The second parameter, tells Ivy to use a resolver named "libraries" as its 
default resolver. More information can be found in the 
link:../settings.html[settings reference documentation].
+The second parameter, tells Ivy to use a resolver named "libraries" as its 
default resolver. More information can be found in the 
link:../settings{outfilesuffix}[settings reference documentation].
 
 === resolvers
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/dual.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/dual.adoc b/asciidoc/tutorial/dual.adoc
index d50b75e..c732a7b 100644
--- a/asciidoc/tutorial/dual.adoc
+++ b/asciidoc/tutorial/dual.adoc
@@ -155,4 +155,4 @@ So everything seemed to work. The Ivy file was found in the 
`repository` directo
 
 This kind of setup can be useful if you don't want to rely on the Maven 2 
repository for metadata, or if you want to take full advantage of Ivy files for 
some or all modules. Combining chain and dual resolvers should give you enough 
flexibility to meet almost any requirement.
 
-For full details about the dual resolver, have a look at the corresponding 
link:../resolver/dual.html[reference documentation].
+For full details about the dual resolver, have a look at the corresponding 
link:../resolver/dual{outfilesuffix}[reference documentation].

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/multiple.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/multiple.adoc b/asciidoc/tutorial/multiple.adoc
index dc17530..c3270e8 100644
--- a/asciidoc/tutorial/multiple.adoc
+++ b/asciidoc/tutorial/multiple.adoc
@@ -147,7 +147,7 @@ Also notice that the `run` Ant target succeeded in using 
both `commons-lang.jar`
 
 == Going further
 
-This very simple example helps us see how to set up two resolvers in a chain. 
The link:../resolver/chain.html[chain resolver's reference documentation] is 
available for those who would like to know all the features offered by this 
resolver.
+This very simple example helps us see how to set up two resolvers in a chain. 
The link:../resolver/chain{outfilesuffix}[chain resolver's reference 
documentation] is available for those who would like to know all the features 
offered by this resolver.
 
 Below are a few more interesting things worth knowing about chain resolvers. 
After reading them, go ahead and try tweaking this example using your new 
wealth of knowledge!
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/multiproject.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/multiproject.adoc 
b/asciidoc/tutorial/multiproject.adoc
index 3d54f76..1f6fefb 100644
--- a/asciidoc/tutorial/multiproject.adoc
+++ b/asciidoc/tutorial/multiproject.adoc
@@ -162,7 +162,7 @@ So, here are some aspects of this common build file:
 
 ----
 
-This declaration configures Ivy by only setting two properties: the location 
for the local repository and the location for the shared repository. It's the 
only settings done here, since Ivy is configured by default to work in a team 
environment (see link:../tutorial/defaultconf.html[default settings tutorial] 
for details about this). For sure in a real environment, the shared repository 
location would rather be in a team shared directory (or in a more complex 
repository, again see the default settings tutorial to see how to use something 
really different).
+This declaration configures Ivy by only setting two properties: the location 
for the local repository and the location for the shared repository. It's the 
only settings done here, since Ivy is configured by default to work in a team 
environment (see link:../tutorial/defaultconf{outfilesuffix}[default settings 
tutorial] for details about this). For sure in a real environment, the shared 
repository location would rather be in a team shared directory (or in a more 
complex repository, again see the default settings tutorial to see how to use 
something really different).
 Commented out you can see how the settings would have been done if the default 
setting wasn't OK for our purpose.
 
 
@@ -204,7 +204,7 @@ You should begin to be familiar with using Ivy this way. We 
call __resolve__ exp
 
 ----
 
-This target is used to ask Ivy to find a new version for a module. To get 
details about the module we are dealing with, we pull information out of the 
Ivy file by using the ivy:info task. Then the 
link:../use/buildnumber.html[buildnumber] task is used to get a new revision, 
based on a prefix we set with a property. By default, it will be 1.0-dev-b 
(have a look at the default value for `module.version.target` in the 
`common/build.properties` file). Each module built by this common build file 
could easily override this by either setting a different 
`module.version.target` in its module specific `build.properties`, or even 
overriding `module.version.prefix`. To get the new revision, Ivy scans the 
repository to find the latest available version with the given prefix, and then 
increments this version by 1.
+This target is used to ask Ivy to find a new version for a module. To get 
details about the module we are dealing with, we pull information out of the 
Ivy file by using the ivy:info task. Then the 
link:../use/buildnumber{outfilesuffix}[buildnumber] task is used to get a new 
revision, based on a prefix we set with a property. By default, it will be 
1.0-dev-b (have a look at the default value for `module.version.target` in the 
`common/build.properties` file). Each module built by this common build file 
could easily override this by either setting a different 
`module.version.target` in its module specific `build.properties`, or even 
overriding `module.version.prefix`. To get the new revision, Ivy scans the 
repository to find the latest available version with the given prefix, and then 
increments this version by 1.
 
 
 === publish
@@ -273,7 +273,7 @@ This target is used when you don't want to use your local 
version of a module an
 
 Generates both an HTML report and a GraphML report.
 
-For example, to generate a graph like the one shown at the beginning of this 
tutorial, you just have to follow the instructions given link:../yed.html[here] 
with the GraphML file you will find in `projects/console/build` after having 
called report in the console project, and that's it, you have a clear overview 
of all your app dependencies!
+For example, to generate a graph like the one shown at the beginning of this 
tutorial, you just have to follow the instructions given 
link:../yed{outfilesuffix}[here] with the GraphML file you will find in 
`projects/console/build` after having called report in the console project, and 
that's it, you have a clear overview of all your app dependencies!
 
 
 == Playing with the projects
@@ -306,4 +306,4 @@ include::asciidoc/tutorial/log/multi-project-find-antp.txt[]
 
 You can see the targets available, thanks to the import of the `common.xml` 
build file. Play with the project by calling resolve, and publish, and see what 
happens when you do the same in other projects. An interesting thing to do, for 
instance, is to change the dependencies of a project. If the module version now 
depends on a new commons library, you will see that all other projects 
depending on that version will get this library as part of their transitive 
dependencies once the new revision of the version project is published. Very 
easy! And if a project introduces a change with which the depender isn't 
compatible yet, you can easily change the dependency in the depender to move 
from `latest.integration` to a fixed version with which the depender is 
compatible (probably the latest before the change). Keeping your modules under 
control is now very easy!
 
-By now, you should be pretty familiar with multi-project development with Ivy. 
We hope you will appreciate its power and flexibility! And these tutorials are 
only the beginning of your journey with Ivy, browse the 
link:../reference.html[reference documentation] to learn more about the 
features, subscribe to the mailing lists to share your experience and ask 
questions with the community, browse the source code, open Jira issues, submit 
patches, join in and help make Ivy the best of dependency management tools!
+By now, you should be pretty familiar with multi-project development with Ivy. 
We hope you will appreciate its power and flexibility! And these tutorials are 
only the beginning of your journey with Ivy, browse the 
link:../reference{outfilesuffix}[reference documentation] to learn more about 
the features, subscribe to the mailing lists to share your experience and ask 
questions with the community, browse the source code, open Jira issues, submit 
patches, join in and help make Ivy the best of dependency management tools!

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/tutorial/start.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/tutorial/start.adoc b/asciidoc/tutorial/start.adoc
index 6959087..522a8d6 100644
--- a/asciidoc/tutorial/start.adoc
+++ b/asciidoc/tutorial/start.adoc
@@ -58,9 +58,9 @@ To know what to put in these attributes, you need to know the 
exact information
     ...
 ----
 
-To convert this into an Ivy dependency declaration, all you have to do is use 
the `groupId` as organization, the `artifactId` as module name, and the version 
as revision. That's what we did for the dependencies in this tutorial, that is 
`commons-lang` and `commons-cli`. Note that having `commons-lang` and 
`commons-cli` as `organization` is not the best example of what the 
organization should be. It would be better to use `org.apache`, 
`org.apache.commons` or `org.apache.commons.lang`. However, this is how these 
specific modules were identified in the Maven 2 repository, so the simplest way 
to get them is to use the details as is (you will see in 
link:../tutorial/build-repository.html[Building a repository] that you can use 
namespaces to redefine these names if you want something cleaner).
+To convert this into an Ivy dependency declaration, all you have to do is use 
the `groupId` as organization, the `artifactId` as module name, and the version 
as revision. That's what we did for the dependencies in this tutorial, that is 
`commons-lang` and `commons-cli`. Note that having `commons-lang` and 
`commons-cli` as `organization` is not the best example of what the 
organization should be. It would be better to use `org.apache`, 
`org.apache.commons` or `org.apache.commons.lang`. However, this is how these 
specific modules were identified in the Maven 2 repository, so the simplest way 
to get them is to use the details as is (you will see in 
link:../tutorial/build-repository{outfilesuffix}[Building a repository] that 
you can use namespaces to redefine these names if you want something cleaner).
 
-If you want more details on what you can do in Ivy files, you can have a look 
at the link:../ivyfile.html[Ivy files reference documentation].
+If you want more details on what you can do in Ivy files, you can have a look 
at the link:../ivyfile{outfilesuffix}[Ivy files reference documentation].
 
 == The build.xml file
 
@@ -84,11 +84,11 @@ You can use the standard `ant -p` command to get the list 
of available targets.
 
 ----
 
-As you can see, it's very easy to call Ivy to resolve and retrieve 
dependencies: all you need if Ivy is properly link:../install.html[installed] 
is to define an XML namespace in your Ant file 
(`xmlns:ivy="antlib:org.apache.ivy.ant"`). Then all the link:../ant.html[Ivy 
Ant tasks] will be available in this namespace.
+As you can see, it's very easy to call Ivy to resolve and retrieve 
dependencies: all you need if Ivy is properly 
link:../install{outfilesuffix}[installed] is to define an XML namespace in your 
Ant file (`xmlns:ivy="antlib:org.apache.ivy.ant"`). Then all the 
link:../ant{outfilesuffix}[Ivy Ant tasks] will be available in this namespace.
 
-Here we use only one task: the link:../use/retrieve.html[retrieve] task. With 
no attributes, it will use default settings and look for a file named `ivy.xml` 
for the dependency definitions. That's exactly what we want, so we need nothing 
more than that.
+Here we use only one task: the link:../use/retrieve{outfilesuffix}[retrieve] 
task. With no attributes, it will use default settings and look for a file 
named `ivy.xml` for the dependency definitions. That's exactly what we want, so 
we need nothing more than that.
 
-Note that in this case we define a `resolve` target and call the 
`link:../use/retrieve.html[retrieve]` task. This may sound confusing, actually 
the retrieve task performs a link:../use/resolve.html[resolve] (which resolves 
dependencies and downloads them to a cache) followed by a retrieve (a copy of 
those file to a local project directory). Check the link:../principle.html[How 
does it work ?] page for details about that.
+Note that in this case we define a `resolve` target and call the 
`link:../use/retrieve{outfilesuffix}[retrieve]` task. This may sound confusing, 
actually the retrieve task performs a 
link:../use/resolve{outfilesuffix}[resolve] (which resolves dependencies and 
downloads them to a cache) followed by a retrieve (a copy of those file to a 
local project directory). Check the link:../principle{outfilesuffix}[How does 
it work ?] page for details about that.
 
 == Running the project
 
@@ -107,7 +107,7 @@ include::asciidoc/tutorial/log/hello-ivy-1.txt[]
 == What happened ?
 
 Without any settings, Ivy retrieves files from the Maven 2 repository. That's 
what happened here.
-The resolve task has found the `commons-lang` and `commons-cli` modules in the 
Maven 2 central repository, identified that `commons-cli` depends on 
`commons-logging` and so resolved it as a transitive dependency. Then Ivy has 
downloaded all corresponding artifacts in its cache (by default in your user 
home, in a `.ivy2/cache` directory). Finally, the retrieve task copies the 
resolved jars from the Ivy cache to the default library directory of the 
project: the `lib` dir (you can change this easily by setting the pattern 
attribute on the link:../use/retrieve.html[retrieve] task).
+The resolve task has found the `commons-lang` and `commons-cli` modules in the 
Maven 2 central repository, identified that `commons-cli` depends on 
`commons-logging` and so resolved it as a transitive dependency. Then Ivy has 
downloaded all corresponding artifacts in its cache (by default in your user 
home, in a `.ivy2/cache` directory). Finally, the retrieve task copies the 
resolved jars from the Ivy cache to the default library directory of the 
project: the `lib` dir (you can change this easily by setting the pattern 
attribute on the link:../use/retrieve{outfilesuffix}[retrieve] task).
 
 You might say that the task took a long time just to write out a "Hello Ivy!" 
message. But remember that a lot of time was spent downloading the required 
files from the web. Let's try to run it again:
 
@@ -121,6 +121,6 @@ include::asciidoc/tutorial/log/hello-ivy-2.txt[]
 
 Great! The cache was used, so no download was needed and the build was 
instantaneous.
 
-And now, if you want to generate a report detailing all the dependencies of 
your module, you can call the report target, and check the generated file in 
the build directory. You should obtain something looking like 
link:../samples/apache-hello-ivy-default.html[this].
+And now, if you want to generate a report detailing all the dependencies of 
your module, you can call the report target, and check the generated file in 
the build directory. You should obtain something looking like 
link:../samples/apache-hello-ivy-default{outfilesuffix}[this].
 
-As you can see, using Ivy to resolve dependencies stored in the Maven 2 
repository is extremely easy. Now you can go on with the other tutorials to 
learn more about link:../tutorial/conf.html[how to use module configurations] 
which is a very powerful Ivy specific feature. More tutorials are also 
available where you will learn how to use Ivy settings to leverage a possibly 
complex enterprise repository. It may also be a good time to start reading the 
link:../reference.html[reference documentation], and especially the 
introduction material which gives a good overview of Ivy. The 
link:../bestpractices.html[best practices] page is also a must read to start 
thinking about how to use Ant+Ivy to build a clean and robust build system.
+As you can see, using Ivy to resolve dependencies stored in the Maven 2 
repository is extremely easy. Now you can go on with the other tutorials to 
learn more about link:../tutorial/conf{outfilesuffix}[how to use module 
configurations] which is a very powerful Ivy specific feature. More tutorials 
are also available where you will learn how to use Ivy settings to leverage a 
possibly complex enterprise repository. It may also be a good time to start 
reading the link:../reference{outfilesuffix}[reference documentation], and 
especially the introduction material which gives a good overview of Ivy. The 
link:../bestpractices{outfilesuffix}[best practices] page is also a must read 
to start thinking about how to use Ant+Ivy to build a clean and robust build 
system.

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/artifactproperty.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/artifactproperty.adoc 
b/asciidoc/use/artifactproperty.adoc
index 584851c..16567f3 100644
--- a/asciidoc/use/artifactproperty.adoc
+++ b/asciidoc/use/artifactproperty.adoc
@@ -21,7 +21,7 @@
 
 Sets an Ant property for each dependency artifact previously resolved.
 
-(*__since 2.0__*) This is a link:../use/postresolvetask.html[post resolve 
task], with all the behaviour and attributes common to all post resolve tasks.
+(*__since 2.0__*) This is a link:../use/postresolvetask{outfilesuffix}[post 
resolve task], with all the behaviour and attributes common to all post resolve 
tasks.
 
 Please prefer the use of retrieve + standard Ant path creation, which make 
your build more independent from Ivy (once artifacts are properly retrieved, 
Ivy is not required any more).
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/artifactreport.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/artifactreport.adoc b/asciidoc/use/artifactreport.adoc
index f4606b7..cf38a42 100644
--- a/asciidoc/use/artifactreport.adoc
+++ b/asciidoc/use/artifactreport.adoc
@@ -19,11 +19,11 @@
 
 [*__since 1.4__*]
 
-The `artifactreport` task generates an XML report of all artifact dependencies 
resolved by the last link:../use/resolve.html[resolve] task call during the 
same build.
+The `artifactreport` task generates an XML report of all artifact dependencies 
resolved by the last link:../use/resolve{outfilesuffix}[resolve] task call 
during the same build.
 
-(*__since 2.0__*) This is a link:../use/postresolvetask.html[post resolve 
task], with all the behaviour and attributes common to all post resolve tasks.
+(*__since 2.0__*) This is a link:../use/postresolvetask{outfilesuffix}[post 
resolve task], with all the behaviour and attributes common to all post resolve 
tasks.
 
-This report is different from the standard link:../use/report.html[report] 
which reports all modules and artifacts, while this report is much simpler and 
focuses only on artifacts, and gives more information on artifacts, such as the 
original location and the retrieve location.
+This report is different from the standard 
link:../use/report{outfilesuffix}[report] which reports all modules and 
artifacts, while this report is much simpler and focuses only on artifacts, and 
gives more information on artifacts, such as the original location and the 
retrieve location.
 
 It is thus easy to use to generate things like a classpath file for an IDE.
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/buildlist.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/buildlist.adoc b/asciidoc/use/buildlist.adoc
index 8ceb4aa..4d827eb 100644
--- a/asciidoc/use/buildlist.adoc
+++ b/asciidoc/use/buildlist.adoc
@@ -23,8 +23,8 @@ The `buildlist` task enables to obtain a `filelist` of files 
(usually `build.xml
 
 This is particularly useful combined with `subant`, to build a set of 
interrelated projects being sure that a dependency will be built before any 
module depending on it.
 
-When the `ivy.xml` of the modules that you want to order doesn't contain 
link:../ivyfile/info.html[revision] numbers, the `rev` attributes declared in 
the dependencies are not used.
-When the `ivy.xml` of the modules that you want to order contains 
link:../ivyfile/info.html[revision] numbers, the revision numbers are used. If 
the revision number doesn't match a dependency description, a warning is logged 
and the modules are considered to be different modules.
+When the `ivy.xml` of the modules that you want to order doesn't contain 
link:../ivyfile/info{outfilesuffix}[revision] numbers, the `rev` attributes 
declared in the dependencies are not used.
+When the `ivy.xml` of the modules that you want to order contains 
link:../ivyfile/info{outfilesuffix}[revision] numbers, the revision numbers are 
used. If the revision number doesn't match a dependency description, a warning 
is logged and the modules are considered to be different modules.
 
 (*__since 1.3__*) A `root` attribute can also be used to include, among all 
the modules found, only the ones that are dependencies (either direct or 
transitive) of a root module. This can also be used with the `excluderoot` 
attribute, which when set to `true` will exclude the root itself from the list.
 
@@ -37,7 +37,7 @@ When the `ivy.xml` of the modules that you want to order 
contains link:../ivyfil
 The `root` and `leaf` attributes can be a delimited list of modules to use as 
roots. These modules, and all their dependencies will be included in the build 
list.
 
 By default, all the modules included in a circular dependency are grouped 
together so that any dependency of any module in the loop will appear before 
the modules in the loop. This guarantees that if there is a dependency path 
between a module A and a module B (but no dependency path from B to A), B will 
always appear before A even if A is included in a loop in the provided set of 
modules to sort.
-Note that a circular dependency can also trigger a failure depending on the 
value configured in the `circularDependencyStrategy` of your 
link:../settings/conf.html#circularDependencyStrategy[settings]
+Note that a circular dependency can also trigger a failure depending on the 
value configured in the `circularDependencyStrategy` of your 
link:../settings/conf{outfilesuffix}#circularDependencyStrategy[settings]
 
 When you are specifying `root` or `leaf` modules you can limit the resulting 
list to only direct dependencies of the root modules or to modules that 
directly depends on your leaf modules.
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/buildobr.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/buildobr.adoc b/asciidoc/use/buildobr.adoc
index 71d1b96..64d2e86 100644
--- a/asciidoc/use/buildobr.adoc
+++ b/asciidoc/use/buildobr.adoc
@@ -19,14 +19,14 @@
 
 [*__since 2.3__*]
 
-From a set of jar artifacts, this task generates an OBR (OSGi Bundle 
Repository) descriptor. It could be then used by the 
link:../resolver/obr.html[obr resolver].
+From a set of jar artifacts, this task generates an OBR (OSGi Bundle 
Repository) descriptor. It could be then used by the 
link:../resolver/obr{outfilesuffix}[obr resolver].
 
 The set of jars which will be described by OBR can be defined in 4 mutually 
exclusive ways:
 
 * via an Ivy resolver: every jar listed by the resolver will be taken into 
account
 * by defining a root directory: every jar found recursively in that folder 
will be taken into account
 * via the name of an Ivy cache: every artifact contained in the cache will be 
taken into account
-* (*__since 2.4__*) via a resolve: this task is a 
link:../use/postresolvetask.html[post resolve task] (with all the behaviour and 
attributes common to all post resolve tasks), thus every artifact which has 
been resolved will be taken into account; it is especially useful for building 
a link:../osgi/target-platform.html[target platform]
+* (*__since 2.4__*) via a resolve: this task is a 
link:../use/postresolvetask{outfilesuffix}[post resolve task] (with all the 
behaviour and attributes common to all post resolve tasks), thus every artifact 
which has been resolved will be taken into account; it is especially useful for 
building a link:../osgi/target-platform{outfilesuffix}[target platform]
 
 NB: among every listed file or artifact, only the actually OSGi bundles will 
be described by the OBR descriptor; the other files are ignored.
 
@@ -34,7 +34,7 @@ NB: among every listed file or artifact, only the actually 
OSGi bundles will be
 
 [*__since 2.4__*]
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks.
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks.
 
 [options="header",cols="15%,50%,35%"]
 |=======

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/cachefileset.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/cachefileset.adoc b/asciidoc/use/cachefileset.adoc
index cd860cc..1582d3c 100644
--- a/asciidoc/use/cachefileset.adoc
+++ b/asciidoc/use/cachefileset.adoc
@@ -21,7 +21,7 @@
 
 Constructs an Ant `fileset` consisting of artifacts in Ivy's cache for a 
configuration.
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks. Note that this task
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks. Note that 
this task
 does not rely on retrieve, because the built fileset is made of artifacts 
directly in Ivy's cache.
 
 Please prefer the use of retrieve + standard Ant path creation, which make 
your build more independent from Ivy (once artifacts are properly retrieved, 
Ivy is not required any more).
@@ -35,7 +35,7 @@ A `fileset`, in Ant project, requires a base directory from 
within which the fil
 
 == Alternative task
 
-If `cachefileset` doesn't fit the need of your use case (maybe due to the 
limitations noted above), the link:../use/resources.html[resources] task could 
be an alternative task to use in certain cases.
+If `cachefileset` doesn't fit the need of your use case (maybe due to the 
limitations noted above), the link:../use/resources{outfilesuffix}[resources] 
task could be an alternative task to use in certain cases.
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/cachepath.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/cachepath.adoc b/asciidoc/use/cachepath.adoc
index 45141f0..18c3284 100644
--- a/asciidoc/use/cachepath.adoc
+++ b/asciidoc/use/cachepath.adoc
@@ -19,9 +19,9 @@
 
 Constructs an Ant `path` consisting of artifacts in Ivy's cache (or origin 
location with depending on `useOrigin` setting) for a resolved module 
configuration.
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks.
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks.
 
-If you want to make your build more independent from Ivy, you could consider 
using the link:../use/retrieve.html[retrieve task]. Once the artifacts are 
properly retrieved, you can use standard Ant path creation which makes Ivy not 
necessary any more.
+If you want to make your build more independent from Ivy, you could consider 
using the link:../use/retrieve{outfilesuffix}[retrieve task]. Once the 
artifacts are properly retrieved, you can use standard Ant path creation which 
makes Ivy not necessary any more.
 
 Built path is registered in the Ant project with a given id, and can thus be 
used like any other Ant path using `refid`.
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/checkdepsupdate.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/checkdepsupdate.adoc 
b/asciidoc/use/checkdepsupdate.adoc
index 24112c0..6459f8e 100644
--- a/asciidoc/use/checkdepsupdate.adoc
+++ b/asciidoc/use/checkdepsupdate.adoc
@@ -19,7 +19,7 @@
 
 Display dependency updates on the console. This task can also show transitive 
dependencies updates and detect missing or new dependencies if you update 
dependencies.
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks.
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks.
 
 Please prefer the use of retrieve + standard Ant path creation, which make 
your build more independent from Ivy (once artifacts are properly retrieved, 
Ivy is not required any more).
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/configure.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/configure.adoc b/asciidoc/use/configure.adoc
index a30f2c1..d16c4f4 100644
--- a/asciidoc/use/configure.adoc
+++ b/asciidoc/use/configure.adoc
@@ -19,13 +19,13 @@
 
 The `configure` task is used to configure Ivy with a settings XML file.
 
-See link:../settings.html[Settings Files] for details about the settings file 
itself.
+See link:../settings{outfilesuffix}[Settings Files] for details about the 
settings file itself.
 
 [*__since 2.0__*]
 
 The file loaded used to be called __configuration__ file in versions prior to 
2.0. The name __settings__ and the use of the `ivy.settings.file` is new to 2.0.
 
-It is also possible to configure Ivy with the 
link:../use/settings.html[settings] declaration. The difference with this task 
is that when using the settings declaration, the configuration of Ivy will be 
done when the settings are first needed (for instance, when you do a resolve), 
while the configure task will perform a configuration of Ivy instantly, which 
makes it easier to see the problem if something goes wrong.
+It is also possible to configure Ivy with the 
link:../use/settings{outfilesuffix}[settings] declaration. The difference with 
this task is that when using the settings declaration, the configuration of Ivy 
will be done when the settings are first needed (for instance, when you do a 
resolve), while the configure task will perform a configuration of Ivy 
instantly, which makes it easier to see the problem if something goes wrong.
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/deliver.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/deliver.adoc b/asciidoc/use/deliver.adoc
index 36f407b..97db767 100644
--- a/asciidoc/use/deliver.adoc
+++ b/asciidoc/use/deliver.adoc
@@ -57,7 +57,7 @@ The delivered Ivy file will update its dependency revisions 
with those given her
 
 == deliver and publish
 
-The `deliver` task is most of the time not called explicitly, but rather 
called automatically by the link:../use/publish.html[publish] task. So, when 
shall the deliver task be called explicitly? When you actually need to separate 
what is performed by the deliver task (see above), from what is performed by 
the `publish` task, i.e. upload a module to a repository.
+The `deliver` task is most of the time not called explicitly, but rather 
called automatically by the link:../use/publish{outfilesuffix}[publish] task. 
So, when shall the deliver task be called explicitly? When you actually need to 
separate what is performed by the deliver task (see above), from what is 
performed by the `publish` task, i.e. upload a module to a repository.
 
 And this can be particularly useful if you want to process the generated Ivy 
file before uploading it (if you want to add automatically more information 
like an SCM tag used, the user who performed the release, ...).
 
@@ -83,11 +83,11 @@ It can also be useful if you want to trigger a recursive 
delivery and then ensur
 |delivertarget|the target to call for recursive delivery|No. No recursive 
delivery is done by default
 |validate|`true` to force Ivy files validation against ivy.xsd, `false` to 
force no validation|No. Defaults to default Ivy value (as configured in 
settings)
 |replacedynamicrev|`true` to replace dynamic revisions by static ones in the 
delivered file, `false` to avoid this replacement (*__since 1.3__*)|No. 
Defaults to `true`
-|replaceForcedRev|`true` to replace revisions (static or dynamic) by the 
revision of the resolver in link:../settings/resolvers.html#common[forced 
mode], `false` to avoid this replacement (*__since 2.2__*)|No. Defaults to 
`false`
-|merge|if a descriptor link:../ivyfile/extends.html[extends] a parent, merge 
the inherited information directly into the delivered descriptor.  The 
`extends` element itself will be commented out in the delivered descriptor. 
(*__since 2.2__*)|No. Defaults to `true`.
+|replaceForcedRev|`true` to replace revisions (static or dynamic) by the 
revision of the resolver in 
link:../settings/resolvers{outfilesuffix}#common[forced mode], `false` to avoid 
this replacement (*__since 2.2__*)|No. Defaults to `false`
+|merge|if a descriptor link:../ivyfile/extends{outfilesuffix}[extends] a 
parent, merge the inherited information directly into the delivered descriptor. 
 The `extends` element itself will be commented out in the delivered 
descriptor. (*__since 2.2__*)|No. Defaults to `true`.
 |settingsRef|A reference to Ivy settings that must be used by this task 
(*__since 2.0__*)|No. Defaults to `ivy.instance`.
 |conf|comma-separated list of configurations to include in the delivered file. 
Accepts wildcards. (*__since 2.0__*)|No. Defaults to all configurations
-|generateRevConstraint|`true` to automatically generate a `revConstraint` 
attribute in the delivered file (see the 
link:../ivyfile/dependency.html[dependency] page for more info about this 
attribute), `false` to never generate this attribute (*__since 2.1__*)|No. 
Defaults to `true`
+|generateRevConstraint|`true` to automatically generate a `revConstraint` 
attribute in the delivered file (see the 
link:../ivyfile/dependency{outfilesuffix}[dependency] page for more info about 
this attribute), `false` to never generate this attribute (*__since 2.1__*)|No. 
Defaults to `true`
 |=======
 
 == Example

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/dependencytree.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/dependencytree.adoc b/asciidoc/use/dependencytree.adoc
index e861205..917817b 100644
--- a/asciidoc/use/dependencytree.adoc
+++ b/asciidoc/use/dependencytree.adoc
@@ -19,7 +19,7 @@
 
 Display a dependency tree on the console.
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks.
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks.
 
 Please prefer the use of retrieve + standard Ant path creation, which make 
your build more independent from Ivy (once artifacts are properly retrieved, 
Ivy is not required any more).
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/findrevision.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/findrevision.adoc b/asciidoc/use/findrevision.adoc
index 60440bb..58fc5d3 100644
--- a/asciidoc/use/findrevision.adoc
+++ b/asciidoc/use/findrevision.adoc
@@ -21,7 +21,7 @@
 
 Finds the latest revision of a module matching a given version constraint.
 
-A version constraint is what is used when declaring a 
link:../ivyfile/dependency.html[dependency] on a module.
+A version constraint is what is used when declaring a 
link:../ivyfile/dependency{outfilesuffix}[dependency] on a module.
 If the module is not found, the property is not set.
 
 == Attributes

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/fixdeps.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/fixdeps.adoc b/asciidoc/use/fixdeps.adoc
index 016f7d6..b9ac31b 100644
--- a/asciidoc/use/fixdeps.adoc
+++ b/asciidoc/use/fixdeps.adoc
@@ -23,7 +23,7 @@ The `fixdeps` task serializes transitively resolved 
dependencies into an `ivy.xm
 
 The dependencies declared in an `ivy.xml` can be specified as range of 
revisions. And the transitive dependencies too. As new versions of modules can 
be added to the repository anytime, resolved versions of ranges can change over 
time. It is then safer to resolve a range once and stick with the resolved 
revision. This way a resolve process is highly reproducible.
 
-It is especially useful in a very dynamic environment like the 
link:../osgi.html[OSGi] one.
+It is especially useful in a very dynamic environment like the 
link:../osgi{outfilesuffix}[OSGi] one.
 
 In a multi project environment some dependencies still need to be maintained 
loose: the ones between the projects. These dependencies, as soon as they are 
declared in the original ivy.xml, can be kept from being fixed. In order to do 
so, use the inner element `keep`.
 
@@ -33,7 +33,7 @@ The recommended setup is then to:
 * have an Ant target which resolves the `ivy-spec.xml` and call `fixdeps` to 
generate an `ivy.xml`. This target should then only be called after 
`ivy-spec.xml` is modified. The generated `ivy.xml` can safely be shared in a 
version control repository (Git, Subversion, ...).
 * make the entire build workflow based on the resolve of the generated 
`ivy.xml`
 
-This is a link:../use/postresolvetask.html[post resolve task], with all the 
behaviour and attributes common to all post resolve tasks.
+This is a link:../use/postresolvetask{outfilesuffix}[post resolve task], with 
all the behaviour and attributes common to all post resolve tasks.
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/listmodules.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/listmodules.adoc b/asciidoc/use/listmodules.adoc
index 31c0e21..d21ca5c 100644
--- a/asciidoc/use/listmodules.adoc
+++ b/asciidoc/use/listmodules.adoc
@@ -23,7 +23,7 @@ Finds the list of modules in the repository matching some 
criteria and sets a co
 
 The criteria is set by given patterns matching the organisation, name branch 
and revision of the modules to find.
 
-To know if a module matches the criteria, Ivy will use the configured 
link:../concept.html#matcher[pattern matcher].
+To know if a module matches the criteria, Ivy will use the configured 
link:../concept{outfilesuffix}#matcher[pattern matcher].
 
 == Attributes
 

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/8736a161/asciidoc/use/postresolvetask.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/postresolvetask.adoc 
b/asciidoc/use/postresolvetask.adoc
index 1257ef3..61e2171 100644
--- a/asciidoc/use/postresolvetask.adoc
+++ b/asciidoc/use/postresolvetask.adoc
@@ -21,18 +21,18 @@ Several tasks in Ivy are considered as post resolve tasks 
and share a common beh
 
 These tasks are:
 
-* link:../use/retrieve.html[retrieve]
-* link:../use/cachefileset.html[cachefileset]
-* link:../use/cachepath.html[cachepath]
-* link:../use/artifactproperty.html[artifactproperty] (*__since 2.0__*)
-* link:../use/artifactreport.html[artifactreport] (*__since 2.0__*)
+* link:../use/retrieve{outfilesuffix}[retrieve]
+* link:../use/cachefileset{outfilesuffix}[cachefileset]
+* link:../use/cachepath{outfilesuffix}[cachepath]
+* link:../use/artifactproperty{outfilesuffix}[artifactproperty] (*__since 
2.0__*)
+* link:../use/artifactreport{outfilesuffix}[artifactreport] (*__since 2.0__*)
 
 All these tasks will trigger a resolve automatically if:
 
 * none has already been called in the current build with the attribute `keep` 
set to `true` (see below)
 * organisation and module are not set
 
-(*__since 1.4__*) There are two ways to run a 
link:../use/resolve.html[resolve]: with an Ivy file, or with the inline mode.
+(*__since 1.4__*) There are two ways to run a 
link:../use/resolve{outfilesuffix}[resolve]: with an Ivy file, or with the 
inline mode.
 When you call resolve with an Ivy file, the default for it is to keep the 
resolved data for use by the subsequent post resolve tasks. When you run an 
inline resolve, the default is not to keep the data. You can override this 
behaviour by setting the keep attribute as you like.
 
 If you want to to reuse the resolved data obtained through a call to resolve 
in another build (i.e. not the current one), then you have to set the 
organisation and module attributes. This work only if the cache was not cleaned 
since your last resolve call. This does not work with inline calls, which must 
be performed in the same build.
@@ -51,9 +51,9 @@ The attributes listed are then mostly used only if a resolve 
is triggered automa
 |module|the name of the module to retrieve. This usually doesn't need to be 
set since it defaults to the last resolved one, except for inline mode where it 
is required.|Yes in inline mode, otherwise no, it then defaults to last 
resolved module name
 |revision|the revision constraint of the module to retrieve. Used only in 
inline mode. (*__since 1.4__*)|No. Defaults to latest.integration
 |branch|the name of the branch to resolve in inline mode (*__since 
2.1__*)|Defaults to no branch in inline mode, nothing in standard mode.
-|changing|indicates that the module may change when resolving in inline mode. 
See link:../concept.html#change[cache and change management] for details. 
Ignored when resolving in standard mode (*__since 2.2__*).|No. Defaults to 
`false`.
+|changing|indicates that the module may change when resolving in inline mode. 
See link:../concept{outfilesuffix}#change[cache and change management] for 
details. Ignored when resolving in standard mode (*__since 2.2__*).|No. 
Defaults to `false`.
 |transitive|`true` to resolve dependencies transitively, `false` otherwise 
(*__since 1.4__*)|No. Defaults to `true`
-|resolveMode|the link:../use/resolve.html[resolve mode] to use when an 
automatic resolve is triggered (*__since 2.1__*)|No. defaults to using the 
resolve mode set in the link:../settings.html[settings]
+|resolveMode|the link:../use/resolve{outfilesuffix}[resolve mode] to use when 
an automatic resolve is triggered (*__since 2.1__*)|No. defaults to using the 
resolve mode set in the link:../settings{outfilesuffix}[settings]
 |keep|`true` to keep the results of the automatic resolve in memory, `false` 
to discard them. When this is `false`, the standard Ivy properties won't be set 
and other post-resolve tasks (like `retrieve` and `cachepath`) won't be able to 
reuse the results of this resolve!|No. defaults to `false` for an inline 
resolve and to `true` in any other case
 |haltonfailure|`true` to halt the build on Ivy failure, `false` to 
continue|No. Defaults to `true`
 |validate|`true` to force Ivy files validation against ivy.xsd, `false` to 
force no validation|No. Defaults to default Ivy value (as configured in 
settings)
@@ -74,16 +74,16 @@ Available options are: +
 
 [*__since 2.3__*]
 
-These child elements are defining an inlined ivy.xml's 
link:../ivyfile/dependencies.html[dependencies] elements. Thus these child 
elements cannot be used together with the `inline` or `file` attributes.
+These child elements are defining an inlined ivy.xml's 
link:../ivyfile/dependencies{outfilesuffix}[dependencies] elements. Thus these 
child elements cannot be used together with the `inline` or `file` attributes.
 
-There is one important difference with the ivy.xml's 
link:../ivyfile/dependencies.html[dependencies]: there is no master 
configuration to handle here. There is actually only one, the one on which the 
resolve will run. So every attribute in 
link:../ivyfile/dependency.html[dependency], 
link:../ivyfile/exclude.html[exclude],  link:../ivyfile/override.html[override] 
or link:../ivyfile/conflict.html[conflict] which is about a master 
configuration is not supported. And every attribute about a mapping of a master 
configuration on a dependency configuration is now expecting only the 
dependency configuration.
+There is one important difference with the ivy.xml's 
link:../ivyfile/dependencies{outfilesuffix}[dependencies]: there is no master 
configuration to handle here. There is actually only one, the one on which the 
resolve will run. So every attribute in 
link:../ivyfile/dependency{outfilesuffix}[dependency], 
link:../ivyfile/exclude{outfilesuffix}[exclude],  
link:../ivyfile/override{outfilesuffix}[override] or 
link:../ivyfile/conflict{outfilesuffix}[conflict] which is about a master 
configuration is not supported. And every attribute about a mapping of a master 
configuration on a dependency configuration is now expecting only the 
dependency configuration.
 
 [options="header",cols="15%,50%,35%"]
 |=======
 |Element|Description|Cardinality
-|link:../ivyfile/dependency.html[dependency]|declares a dependency to 
resolve|0..n
-|link:../ivyfile/exclude.html[exclude]|excludes artifacts, modules or whole 
organizations from the set of dependencies to resolve|0..n
-|link:../ivyfile/override.html[override]|specify an override mediation rule, 
overriding the revision and/or branch requested for a transitive dependency 
(*__since 2.0__*)|0..n
+|link:../ivyfile/dependency{outfilesuffix}[dependency]|declares a dependency 
to resolve|0..n
+|link:../ivyfile/exclude{outfilesuffix}[exclude]|excludes artifacts, modules 
or whole organizations from the set of dependencies to resolve|0..n
+|link:../ivyfile/override{outfilesuffix}[override]|specify an override 
mediation rule, overriding the revision and/or branch requested for a 
transitive dependency (*__since 2.0__*)|0..n
 |=======
 
 == Examples

Reply via email to