You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by gi...@apache.org on 2018/03/13 22:31:36 UTC
[2/3] ant-ivy git commit: More navigation fixes
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