You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by hi...@apache.org on 2017/06/30 14:15:14 UTC
[4/4] ant-ivy git commit: Review and cleanup of the "Ant tasks" part
of the documentation
Review and cleanup of the "Ant tasks" part of the documentation
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/25a67d80
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/25a67d80
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/25a67d80
Branch: refs/heads/master
Commit: 25a67d80c6e0dbbe75a4cd14bad009b1fc840d27
Parents: cda1bd3
Author: Nicolas Lalevée <ni...@hibnet.org>
Authored: Fri Jun 30 16:14:45 2017 +0200
Committer: Nicolas Lalevée <ni...@hibnet.org>
Committed: Fri Jun 30 16:14:45 2017 +0200
----------------------------------------------------------------------
asciidoc/ant.adoc | 55 ++------
asciidoc/style/style.css | 16 ++-
asciidoc/use/artifactproperty.adoc | 34 ++---
asciidoc/use/artifactreport.adoc | 21 +--
asciidoc/use/buildlist.adoc | 101 ++++++---------
asciidoc/use/buildnumber.adoc | 61 +++------
asciidoc/use/buildobr.adoc | 35 +----
asciidoc/use/cachefileset.adoc | 28 ++--
asciidoc/use/cachepath.adoc | 32 ++---
asciidoc/use/checkdepsupdate.adoc | 24 +---
asciidoc/use/cleancache.adoc | 19 +--
asciidoc/use/configure.adoc | 58 +++------
asciidoc/use/convertmanifest.adoc | 14 +-
asciidoc/use/convertpom.adoc | 8 +-
asciidoc/use/deliver.adoc | 94 +++++---------
asciidoc/use/dependencytree.adoc | 22 +---
asciidoc/use/findrevision.adoc | 17 +--
asciidoc/use/fixdeps.adoc | 39 ++----
asciidoc/use/info.adoc | 35 ++---
asciidoc/use/install.adoc | 29 ++---
asciidoc/use/listmodules.adoc | 23 ++--
asciidoc/use/makepom.adoc | 90 +++++--------
asciidoc/use/postresolvetask.adoc | 80 ++++--------
asciidoc/use/publish.adoc | 60 ++++-----
asciidoc/use/report.adoc | 32 ++---
asciidoc/use/repreport.adoc | 45 ++-----
asciidoc/use/resolve.adoc | 223 +++++++++-----------------------
asciidoc/use/resources.adoc | 43 +-----
asciidoc/use/retrieve.adoc | 127 +++++-------------
asciidoc/use/settings.adoc | 62 +++------
asciidoc/use/var.adoc | 17 +--
asciidoc/yed.adoc | 17 +--
32 files changed, 469 insertions(+), 1092 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/ant.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ant.adoc b/asciidoc/ant.adoc
index 955d11a..c424333 100644
--- a/asciidoc/ant.adoc
+++ b/asciidoc/ant.adoc
@@ -17,45 +17,35 @@
under the License.
////
-The main and most frequent way to use ivy is from an ant build file. However, ivy can also be called as a standalone application
+The main and most frequent way to use Ivy is from an Ant build file. However, Ivy can also be called as a standalone application
-If you use ant version *1.6.0* or superior, you just have to add ivy namespace to your project (
-[source]
-----
-xmlns:ivy="antlib:org.apache.ivy.ant"
-----
-
-attribute of your project tag), and you can call ivy tasks.
+If you use ant version *1.6.0* or superior, you just have to add Ivy's namespace to your project (`xmlns:ivy="antlib:org.apache.ivy.ant"` attribute of your project tag), and you can call Ivy tasks.
If you want to make your build handle ivy.jar in either ant lib dir or a local lib dir, you can use a taskdef like this:
[source]
----
-
<path id="ivy.lib.path">
<fileset dir="path/to/dir/with/ivy/jar" includes="*.jar"/>
</path>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path"/>
-
----
-Combined with the antlib definition in the project namespace, it will load Ivy classes either from your ant lib or a local directory (path/to/dir/with/ivy/jar in this example).
+Combined with the antlib definition in the project namespace, it will load Ivy classes either from your ant lib or a local directory (`path/to/dir/with/ivy/jar` in this example).
If you use ant *1.5.1* or superior, you have to define the tasks you use in your build file. For instance:
[source]
----
-
<taskdef name="ivy-configure" classname="org.apache.ivy.ant.IvyConfigure"/>
<taskdef name="ivy-resolve" classname="org.apache.ivy.ant.IvyResolve"/>
<taskdef name="ivy-retrieve" classname="org.apache.ivy.ant.IvyRetrieve"/>
<taskdef name="ivy-deliver" classname="org.apache.ivy.ant.IvyDeliver"/>
<taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
-
----
-_Note: the tasks listed above are non exhaustive. For a complete list of tasks with the corresponding classes, see the link:https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=src/java/org/apache/ivy/ant/antlib.xml[antlib.xml] file in git or the version you use._
+_Note_: the tasks listed above are non exhaustive. For a complete list of tasks with the corresponding classes, see the link:https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=src/java/org/apache/ivy/ant/antlib.xml[antlib.xml] file in git or the version you use.
Then you can use the tasks, but check their name, following samples assume you use the ivy namespace (ivy:xxx tasks), whereas with ant 1.5 you cannot use namespace, and should therefore use ivy-xxx tasks if you have followed the taskdefs above.
@@ -67,16 +57,13 @@ Once your build file is ok to call ivy tasks, the simplest way to use ivy is to
[source]
----
-
<ivy:retrieve />
-
----
This calls ivy with default values, which might be ok in several projects. In fact, it is equivalent to:
[source]
----
-
<target name="resolve">
<ivy:configure />
@@ -84,24 +71,18 @@ This calls ivy with default values, which might be ok in several projects. In fa
<ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}" />
</target>
-
----
Those 3 tasks follow the 3 main steps of the ivy retrieving dependencies process:
-
-* First the configure task tells it how it can find dependencies giving it a path to an link:settings.html[xml settings file]. +
-
-* Then the resolve task actually resolves dependencies described by an link:ivyfile.html[ivy file], and puts those dependencies in the ivy cache (a directory configured in the settings file). +
-
-* Finally the retrieve task copies dependencies from the cache to anywhere you want in your file system. You can then use those dependencies to make your classpath with standard ant paths. +
-
+* First the configure task tells it how it can find dependencies giving it a path to an link:settings.html[xml settings file].
+* Then the resolve task actually resolves dependencies described by an link:ivyfile.html[ivy file], and puts those dependencies in the ivy cache (a directory configured in the settings file).
+* Finally the retrieve task copies dependencies from the cache to anywhere you want in your file system. You can then use those dependencies to make your classpath with standard ant paths.
To understand more accurately the behaviour of ivy tasks, one should know that a property file is loaded in ant by ivy at the beginning of the configure call. This property file contains the following properties:
[source]
----
-
ivy.project.dir = ${basedir}
ivy.lib.dir = ${ivy.project.dir}/lib
ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
@@ -124,44 +105,37 @@ ivy.report.output.pattern = [organisation]-[module]-[conf].[ext]
ivy.buildlist.ivyfilepath = ivy.xml
ivy.checksums=sha1,md5
-
----
_For the latest version of these properties, you can check the link:https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=src/java/org/apache/ivy/core/settings/ivy.properties[git version]._
-*__since 2.0__* After calling the first Ivy task, the property ivy.version will be available and contains the version of the used Ivy library.
+*__since 2.0__* After calling the first Ivy task, the property `ivy.version` will be available and contains the version of the used Ivy library.
== Ivy tasks attributes : generalities
Some tasks attributes values may be given through different places. The three possible places are :
-
-. task attribute +
-
-. ivy instance +
-
-. project property +
+. task attribute
+. ivy instance
+. project property
The places are queried in this order, so anything set in task attribute will overwrite what would have been found in ivy instance, for example.
-The ivy instance considered here is an instance of the class Ivy, which is setup by a call to the configure task, and then reused for other tasks. Because most of the tasks need an ivy instance, they first check if one is available (i.e. configure has been called), and if none is available, then a default configure is called and the resulting ivy instance is used in the remaining tasks (unless another configure is called).
+The Ivy instance considered here is an instance of the class `Ivy`, which is setup by a call to the configure task, and then reused for other tasks. Because most of the tasks need an Ivy instance, they first check if one is available (i.e. configure has been called), and if none is available, then a default configure is called and the resulting Ivy instance is used in the remaining tasks (unless another configure is called).
It isn't generally necessary to understand this, but it can lead to some issues if you forget to call configure before another task and if the configure step was required in your environment.
-
== Usual cycle of main tasks
image::images/main-tasks.png[]
== Example
-Here is a more complete example of build file using ivy:
-
+Here is a more complete example of build file using Ivy:
[source]
----
-
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="sample" default="resolve">
<target name="resolve">
@@ -194,7 +168,6 @@ Here is a more complete example of build file using ivy:
pubrevision="1.1b4" />
</target>
</project>
-
----
-All ivy tasks are documented in the following pages.
+All Ivy tasks are documented in the following pages.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/style/style.css
----------------------------------------------------------------------
diff --git a/asciidoc/style/style.css b/asciidoc/style/style.css
index 289760b..83b6f9d 100644
--- a/asciidoc/style/style.css
+++ b/asciidoc/style/style.css
@@ -101,6 +101,9 @@ pre {
padding: 0.75em 1.5em;
font-size: 1em;
}
+code {
+ background-color: #EEE;
+}
.form-item {
margin-top: 1em;
}
@@ -110,7 +113,11 @@ pre {
.hide {
display: none
}
-
+.imageblock {
+ margin: 10px;
+ padding: 10px;
+ text-align: center;
+}
/*
** Page layout blocks / IDs
*/
@@ -350,7 +357,12 @@ table.tableblock td {
table.tableblock td p:last-child {
margin: 0px;
}
-
+table.tableblock .halign-center {
+ text-align: center;
+}
+table.tableblock .valign-middle {
+ vertical-align: middle;
+}
.note {
padding: 15px;
border-style:solid;
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/artifactproperty.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/artifactproperty.adoc b/asciidoc/use/artifactproperty.adoc
index 7dde090..19ab13c 100644
--- a/asciidoc/use/artifactproperty.adoc
+++ b/asciidoc/use/artifactproperty.adoc
@@ -18,58 +18,48 @@
////
*__since 1.1__*
-Sets an ant property for each dependency artifacts previously resolved.
+Sets an Ant property for each dependency artifacts 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.
-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).
+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).
-The property name and value are generated using the classical pattern concept, all artifact tokens and ivy variables being available.
-
-*__since 2.0__* This tag will follow the ant usual behavior for properties. If a property of the same name already exist, it's value will be unchanged. This behavior can be changed using the 'overwrite' attribute.
-__WARNING : Before 2.0, the behavior was to overwrite the properties. Since 2.0, the default is to not overwrite to properties__
+The property name and value are generated using the classical pattern concept, all artifact tokens and Ivy variables being available.
+*__since 2.0__* This tag will follow the ant usual behavior for properties. If a property of the same name already exist, it's value will be unchanged. This behavior can be changed using the `overwrite` attribute.
+_WARNING_: Before 2.0, the behavior was to overwrite the properties. Since 2.0, the default is to not overwrite to properties
== Attributes
-
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|name|a pattern used to generate the name of the properties to set|Yes
|value|a pattern used to generate the value of the properties to set|Yes
-|conf|a comma separated list of the configurations for which properties should be set|No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
-|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 configuration file)
-|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, 'ivy.instance' is taken by default.
-|overwrite|Overwrite the value of the property if it already exist *(since 2.0)*. Before 2.0, the properties were always overwritten.|No, 'false' by default.
+|conf|a comma separated list of the configurations for which properties should be set|No. Defaults to the configurations resolved by the last resolve call, or `$$*$$` if no resolve was explicitly called
+|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 configuration file)
+|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, `ivy.instance` is taken by default.
+|overwrite|Overwrite the value of the property if it already exist *(since 2.0)*. Before 2.0, the properties were always overwritten.|No, `false` by default.
|=======
-
-
== Example
-Suppose we have one dependency called __mydep__ in revision 1.0 publishing two artifacts: __foo.jar__ and __bar.jar__.
+Suppose we have one dependency called `mydep` in revision 1.0 publishing two artifacts: `foo.jar` and `bar.jar`.
Then:
[source]
----
-
-<artifactproperty conf="build"
+<artifactproperty conf="build"
name="[module].[artifact]-[revision]"
value="${cache.dir}/[module]/[artifact]-[revision].[ext]"/>
-
----
will set two properties:
[source]
----
-
mydep.foo-1.0 = my/cache/dir/mydep/foo-1.0.jar
mydep.bar-1.0 = my/cache/dir/mydep/bar-1.0.jar
-
----
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/artifactreport.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/artifactreport.adoc b/asciidoc/use/artifactreport.adoc
index 2d1ef9f..86df3d5 100644
--- a/asciidoc/use/artifactreport.adoc
+++ b/asciidoc/use/artifactreport.adoc
@@ -18,7 +18,7 @@
////
*__since 1.4__*
-The artifactreport task generates an xml report of all artifacts 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 artifacts dependencies resolved by the last link:../use/resolve.html[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.
@@ -32,7 +32,6 @@ Here is an example of generate file:
[source]
----
-
<?xml version="1.0" encoding="UTF-8"?>
<modules>
<module organisation="hippo" name="sant-classes" rev="1.01.00b04-dev" status="integration">
@@ -58,43 +57,33 @@ Here is an example of generate file:
<cache-location>C:/home/jstuyts/data/ivy/cache/testng/testng/jars/testng-4.6.1-jdk15.jar</cache-location>
<retrieve-location>lib/test/testng-4.6.1-jdk15.jar</retrieve-location>
</artifact>
- </module>
-
+ </module>
----
-
== Attributes
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|tofile|the file to which the report should be written|Yes
-|pattern|the retrieve pattern to use to fill the retrieve location information about the artifacts|No. Defaults to ${ivy.retrieve.pattern}.
+|pattern|the retrieve pattern to use to fill the retrieve location information about the artifacts|No. Defaults to `${ivy.retrieve.pattern}`.
|conf|a comma separated list of the configurations to use to generate the report|No. Defaults to the configurations resolved by the last resolve call
-|haltonfailure|true to halt the build on ivy failure, false to continue|No. Defaults to true
-|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, 'ivy.instance' is taken by default.
+|haltonfailure|`true` to halt the build on ivy failure, `false` to continue|No. Defaults to `true`
+|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, `ivy.instance` is taken by default.
|=======
-
== Examples
-
[source]
----
-
<ivy:artifactreport tofile="${basedir}/path/to/myreport.xml" />
-
----
Generates the artifact report for all configurations resolved during the last resolve call (in the same build).
-
[source]
----
-
<ivy:artifactreport tofile="${basedir}/path/to/myreport.xml" conf="default"/>
-
----
Generates the artifact report for only the default configuration resolved during the last resolve call.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/buildlist.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/buildlist.adoc b/asciidoc/use/buildlist.adoc
index 4b79664..8d55ab5 100644
--- a/asciidoc/use/buildlist.adoc
+++ b/asciidoc/use/buildlist.adoc
@@ -17,145 +17,116 @@
under the License.
////
-The buildlist task enable to obtain a filelist of files (usually build.xml files) ordered according to ivy dependency information from the least dependent to the most one, or the inverse. (*__since 1.2__*)
+The `buildlist` task enable to obtain a `filelist` of files (usually `build.xml` files) ordered according to Ivy dependency information from the least dependent to the most one, or the inverse. (*__since 1.2__*)
-This is particularly useful combined with subant, to build a set of interelated projects being sure that a dependency will be built before any module depending on it.
+This is particularly useful combined with `subant`, to build a set of interelated 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 contains a link:../ivyfile/info.html[revision] numbers, the rev attributes declared in the dependency is not used.
-When the ivy.xml of the modules that you want to order contains a 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 is considered as different modules.
+When the `ivy.xml` of the modules that you want to order doesn't contains a link:../ivyfile/info.html[revision] numbers, the `rev` attributes declared in the dependency is not used.
+When the `ivy.xml` of the modules that you want to order contains a 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 is considered as different modules.
-*__since 1.3__* A root attribute can also be used to include, among all the modules found, only the one 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.
+*__since 1.3__* A `root` attribute can also be used to include, among all the modules found, only the one 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.
-*__since 1.4.1__* A leaf attribute can also be used to include, among all the modules found, only the one that have dependencies (either direct or transitive) on a leaf module. This can also be used with the excludeleaf attribute, which when set to true will exclude the leaf itself from the list.
+*__since 1.4.1__* A `leaf` attribute can also be used to include, among all the modules found, only the one that have dependencies (either direct or transitive) on a leaf module. This can also be used with the `excludeleaf` attribute, which when set to `true` will exclude the leaf itself from the list.
-*__since 1.4__* The ivy.sorted.modules property is set in the ant at the end of the task with a comma separated list of ordered modules. This can be useful for debug or information purpose.
+*__since 1.4__* The `ivy.sorted.modules` property is set in the ant at the end of the task with a comma separated list of ordered modules. This can be useful for debug or information purpose.
-*__since 2.0__* 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.
+*__since 2.0__* 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.
*__since 2.0__* By default, all the modules included in a circular dependency are grouped together so that any dependency of any module in the loop will apear before the modules in the loop. This garantee that if there is a depedendency path between a module A and a module B (but no dependency path from B to A), B will alway apear before A even if A is included in a loop in the provided set of modules to sort.
-Note that 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 circular dependency can also trigger a failure depending on the value configured in the `circularDependencyStrategy` of your link:../settings/conf.html#circularDependencyStrategy[settings]
-*__since 2.0__* When you are specifying root or leaf modules you can limit the resulting list to only direct dependencies of the roots modules or to modules that directly depends on your leaf modules.
-
-*__since 2.0__* You can also specify a restartFrom modules. The difference with root or leaf, is that you get a list starting at the restartFrom module followed by all the modules that would be after if the parameter would not be there (even if there is no dependency between the restartFrom and the following module).
+*__since 2.0__* When you are specifying `root` or `leaf` modules you can limit the resulting list to only direct dependencies of the roots modules or to modules that directly depends on your leaf modules.
+*__since 2.0__* You can also specify a `restartFrom` modules. The difference with `root` or `leaf`, is that you get a list starting at the `restartFrom` module followed by all the modules that would be after if the parameter would not be there (even if there is no dependency between the `restartFrom` and the following module).
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|reference|the reference of the path to set|Yes
-|ivyfilepath|the relative path from files to order to corresponding ivy files|No. Defaults to ${ivy.buildlist.ivyfilepath}
-|root|*__since 2.0__* the names of the modules which should be considered as the root of the buildlist.
+|ivyfilepath|the relative path from files to order to corresponding ivy files|No. Defaults to `${ivy.buildlist.ivyfilepath}`
+|root|*__since 2.0__* the names of the modules which should be considered as the root of the buildlist.
+
*__since 1.3__* Was limited to only one module name before 2.0.|No. Defaults to no root (all modules are used in the build list)
-|excluderoot|*__since 1.3__* true if the root defined should be excluded from the list|No. Defaults to false
+|excluderoot|*__since 1.3__* `true` if the root defined should be excluded from the list|No. Defaults to `false`
|leaf|*__since 2.0__* the names of the modules which should be considered as the leaf of the buildlist.
*__since 1.4.1__* Was limited to only one module name before 2.0.|No. Defaults to no leaf (all modules are used in the build list)
-|onlydirectdep|*__since 2.0__* true if the
+|onlydirectdep|*__since 2.0__* `true` if the
resulting list should be restricted to direct dependencies of root modules or modules that directly depends on the leaf modules.
This field is ignored when neither root neither leaf is filled.
- |No. Defaults to no false
-|delimiter|*__since 2.0__* delimiter to use when specifying multiple module names in the root and leaf properties.|No. Defaults to the comma (,) character.
-|excludeleaf|*__since 1.4.1__* true if the leaf defined should be excluded from the list|No. Defaults to false
-|haltonerror|true to halt the build when an invalid ivy file is encountered, false to continue|No. Defaults to true
-|skipbuildwithoutivy|Deprecated, use onMissingDescriptor instead. true to skip files of the fileset with no corresponding ivy file, false otherwise. If false the file with no corresponding ivy file will be considered as independent of the other and put at the beginning of the built filelist.|No. Defaults to false
-|onMissingDescriptor|*__since 2.0__* Specify the action to take when no module descriptor file is found for a file of the fileset. Possible values are:
-
-
-* head +
-put at the head of the built filelist.
-
-* tail +
-put at the tail of the built filelist.
-
-* skip +
-skip the file, which won't be put in the build filelist at all.
-
-* warn +
-warn and put at the head of the build filelist.
-
-* fail +
-halt the build with a failure.
-
- |No. Defaults to 'head'
-|reverse|true to obtain the list in the reverse order, i.e. from the most dependent to the least one|No. Defaults to default false
+ |No. Defaults to no `false`
+|delimiter|*__since 2.0__* delimiter to use when specifying multiple module names in the root and leaf properties.|No. Defaults to the comma (`,`) character.
+|excludeleaf|*__since 1.4.1__* `true` if the leaf defined should be excluded from the list|No. Defaults to `false`
+|haltonerror|`true` to halt the build when an invalid ivy file is encountered, false to continue|No. Defaults to `true`
+|skipbuildwithoutivy|Deprecated, use `onMissingDescriptor` instead. `true` to skip files of the fileset with no corresponding ivy file, `false` otherwise. If `false` the file with no corresponding ivy file will be considered as independent of the other and put at the beginning of the built filelist.|No. Defaults to `false`
+|onMissingDescriptor|*__since 2.0__* Specify the action to take when no module descriptor file is found for a file of the fileset. Possible values are: +
+* `head`: put at the head of the built filelist. +
+* `tail`: put at the tail of the built filelist. +
+* `skip`: skip the file, which won't be put in the build filelist at all. +
+* `warn`: warn and put at the head of the build filelist. +
+* `fail`: halt the build with a failure.
+ |No. Defaults to `head`
+|reverse|`true` to obtain the list in the reverse order, i.e. from the most dependent to the least one|No. Defaults to default `false`
|restartFrom|*__since 2.0__* The name of the module which should be considered as the starting point in the buildlist. This allows for the build to be started at any point in the dependency chain.
-|No. Defaults to '*' meaning no restart point (all modules are used in the build list).
-|settingsRef|*__since 2.0__* A reference to the ivy settings that must be used by this task|No, 'ivy.instance' is taken by default.
+|No. Defaults to `*` meaning no restart point (all modules are used in the build list).
+|settingsRef|*__since 2.0__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default.
|=======
-
-
== Parameters specified as nested elements
-
=== fileset
FileSets are used to select sets of files to order.
== Examples
-
[source]
----
-
<ivy:buildlist reference="build-path">
<fileset dir="projects" includes="**/build.xml"/>
</ivy:buildlist>
-
----
-Builds a list of build.xml files sorted according to the ivy.xml files found at the same level (the default value for ivyfilepath is ivy.xml).
+Builds a list of `build.xml` files sorted according to the `ivy.xml` files found at the same level (the default value for `ivyfilepath` is `ivy.xml`).
This list can then be used like that:
[source]
----
-
<subant target="build" buildpathref="build-path" />
-
----
-
'''
-
[source]
----
-
<ivy:buildlist reference="build-path" ivyfilepath="ivy/ivy.xml" reverse="true">
<fileset dir="projects" includes="**/build.xml"/>
</ivy:buildlist>
-
----
-Builds a list of build.xml files sorted according to the ivy.xml files found in an ivy directory relative to those build files. The list is sorted from the most dependent to the least one.
+Builds a list of `build.xml` files sorted according to the `ivy.xml` files found in an ivy directory relative to those build files. The list is sorted from the most dependent to the least one.
'''
-
[source]
----
-
<ivy:buildlist reference="build-path" ivyfilepath="ivy/ivy.xml" root="myapp">
<fileset dir="projects" includes="**/build.xml"/>
</ivy:buildlist>
-
----
-Builds a list of build.xml files sorted according to the ivy.xml files found in an ivy directory relative to those build files. Only build.xml files of modules which are dependencies of myapp (either direct or transitive) are put in the result list.
+Builds a list of `build.xml` files sorted according to the `ivy.xml` files found in an ivy directory relative to those build files. Only `build.xml` files of modules which are dependencies of `myapp` (either direct or transitive) are put in the result list.
'''
-
[source]
----
-
<ivy:buildlist reference="build-path" ivyfilepath="ivy/ivy.xml" leaf="mymodule">
<fileset dir="projects" includes="**/build.xml"/>
</ivy:buildlist>
-
----
-Builds a list of build.xml files sorted according to the ivy.xml files found in an ivy directory relative to those build files. Only build.xml files of modules which have dependencies (direct or transitive) on mymodule are put in the result list.
+Builds a list of `build.xml` files sorted according to the `ivy.xml` files found in an ivy directory relative to those build files. Only `build.xml` files of modules which have dependencies (direct or transitive) on `mymodule` are put in the result list.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/buildnumber.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/buildnumber.adoc b/asciidoc/use/buildnumber.adoc
index 026baee..cb53e93 100644
--- a/asciidoc/use/buildnumber.adoc
+++ b/asciidoc/use/buildnumber.adoc
@@ -18,29 +18,22 @@
////
*__since 1.4__*
-The buildnumber task is similar to the ant buildnumber task, except that it uses ivy repository to find what is the latest version and calculate a new one for you.
+The `buildnumber` task is similar to the Ant `buildnumber` task, except that it uses Ivy repository to find what is the latest version and calculate a new one for you.
-When called it sets four properties according to what has been found.
-These properties are:
+When called it sets four properties according to what has been found. These properties are:
+* `ivy.revision`: the last revision found in the repository
+* `ivy.new.revision`: the new revision calculated from the last one (see below)
+* `ivy.build.number`: the build number found in the repository
+* `ivy.new.build.number`: the new build number calculated from the last one, usually with +1
-* ivy.revision +
- the last revision found in the repository
+Build numbers are always numbers (composed of digit characters only).
-* ivy.new.revision +
- the new revision calculated from the last one (see below)
+`ivy.revision` can be not set if no revision was found.
-* ivy.build.number +
- the build number found in the repository
+`ivy.build.number` can be not set if no revision was found or if no number was found in it.
-* ivy.new.build.number +
- the new build number calculated from the last one, usually with +1
-
-
-build numbers are always numbers (composed of digit characters only).
-ivy.revision can be not set if no revision was found
-ivy.build.number can be not set if no revision was found or if no number was found in it
-ivy.new.build.number can be not set if the default new revision to use when no revision is found do not contain any number
+`ivy.new.build.number` can be not set if the default new revision to use when no revision is found do not contain any number.
The new revision is calculated using a somewhat complex to explain but very easy to use algorithm, depending on which latest version you asked.
@@ -48,9 +41,9 @@ Indeed you can ask for a new revision based upon the latest found for a particul
Examples (suppose the latest version of the module is 1.3.1):
-[]
+[options="header",cols="5*^.^"]
|=======
-
+| revision asked | ivy.revision | ivy.new.revision | ivy.build.number | ivy.new.build.number
|1.3|1.3.1|1.3.2|1|2
|1|1.3.1|1.4|3|4
|2|not set|2.0|not set|0
@@ -59,6 +52,7 @@ Examples (suppose the latest version of the module is 1.3.1):
Note that when asking for revision 1, you can get a revision 10.0. To avoid that you can use 1. as revision asked, but in this case ivy won't find revision 1 if its the latest one, and it will thus give 1.0 as new revision. The solution to this problem is to use versions with always the same number of parts (for instance 1.0.0 instead of 1).
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
@@ -69,87 +63,64 @@ Note that when asking for revision 1, you can get a revision 10.0. To avoid that
|revision|the revision prefix for which a new build number should be calculated|No, defaults to no prefix (will find the latest version)
|default|the default revision to assume when no revision prefix is asked and no revision is found|No, defaults to 0
|defaultBuildNumber|the default build number to use for the first revision|No, defaults to 0
-|revSep|the revision separator to use when no matching revision is found, to separate the revision prefix from the build number|No, defaults to '.'
-|prefix|the prefix to use for the property names set (will be __prefix__.revision, __prefix__.new.revision, ...)|No, defaults to ivy
-|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*.|No, 'ivy.instance' is taken by default.
+|revSep|the revision separator to use when no matching revision is found, to separate the revision prefix from the build number|No, defaults to `.`
+|prefix|the prefix to use for the property names set (will be `__prefix__.revision, __prefix__.new.revision, ...)|No, defaults to `ivy`
+|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*.|No, `ivy.instance` is taken by default.
|resolver|the name of the resolver to use for build number calculation *__(since 2.1)__*|No, all available resolvers will be used by default.
|=======
-
== Examples
Here is how it can be used (suppose 1.3.1 is the latest version of ivy in the repository):
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" />
-
----
will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as new build number
-
'''
-
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" revision="1.3" />
-
----
will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as new build number
-
'''
-
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" revision="1.2" />
-
----
will set 1.2 as revision, 1.2.1 as new revision, no build number and 1 as new build number
-
'''
-
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" revision="1." />
-
----
will set 1.3.1 as revision, 1.4 as new revision, 3 as build number and 4 as new build number
-
'''
-
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" revision="3." />
-
----
will set no revision, 3.0 as new revision, no build number and 0 as new build number
-
'''
-
[source]
----
-
<ivy:buildnumber organisation="apache" module="ivy" revision="1.4-RC" defaultBuildNumber="1" revSep=""/>
-
----
If called while no release candidate is in the repository, will set ivy.revision to 1.4-RC1. Then it will increment each time, 1.4-RC2, 1.4-RC3, and so on.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/buildobr.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/buildobr.adoc b/asciidoc/use/buildobr.adoc
index 497af55..b8ddc94 100644
--- a/asciidoc/use/buildobr.adoc
+++ b/asciidoc/use/buildobr.adoc
@@ -21,25 +21,17 @@
The set of jars which will be described by the OBR can be defined in 4 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 ever artifact which has been resolved will be taken into account; it is especially useful for building a link:../osgi/target-platform.html[target platform] +
-
+* 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 ever artifact which has been resolved will be taken into account; it is especially useful for building a link:../osgi/target-platform.html[target platform]
NB: among every listed files or artifacts, only the actually OSGi bundles will be described by the OBR descriptor; the other files are ignored.
-
== Attributes
-
*__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.
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
@@ -47,65 +39,48 @@ NB: among every listed files or artifacts, only the actually OSGi bundles will b
|resolverName|the name of the resolver from which the jars should be to gathered|No
|cacheName|the name of the cache from which the jars should be to gathered|No
|baseDir|the folder into which the jars should be gather recursively|No
-|sourceType|if used as a post resolve task, 'sourceType' define the type of artifacts which should be considered as source artifacts (defaults to 'source,sources,src')|No
+|sourceType|if used as a post resolve task, `sourceType` define the type of artifacts which should be considered as source artifacts|No. Defaults to `source,sources,src`
|encoding|The encoding of the resulting xml file|No. Defaults to `UTF-8`
|indent|Specify if the xml result file should be indented|No. Defaults to `true`
|quiet|Log as debug rather than warning the rejected jars as they are illformed|No. Defaults to `false`
|=======
-
-
== Examples
-
[source]
----
-
<ivy:buildobr baseDir="${eclipse.home}" out="${basedir}/target/repo-eclipse.xml" indent="true" />
-
----
Builds an indented OBR descriptor from an Eclipse install, with their path relative to the Eclipse install.
-
'''
-
[source]
----
-
<ivy:configure file="ivysettings.xml" />
<ivy:buildobr resolverName="my-file-resolver" out="${basedir}/target/repo-eclipse.xml" />
-
----
Configure an Ivy settings and builds an OBR descriptor from jars resolved by the defined resolver.
-
'''
-
[source]
----
-
<ivy:configure file="ivysettings.xml" />
<ivy:buildobr cacheName="my-cache" out="${basedir}/target/repo-eclipse.xml" />
-
----
Configure an Ivy settings and builds an OBR descriptor from jars contained in the defined cache.
-
'''
-
[source]
----
-
<ivy:configure file="ivysettings.xml" />
<ivy:resolve file="ivy.xml" />
<ivy:buildobr out="${basedir}/target-platform-obr.xml" />
-
----
Launch a resolve and then build an obr.xml describing the resolved artifacts.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/cachefileset.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/cachefileset.adoc b/asciidoc/use/cachefileset.adoc
index 8dfe5b7..2902ab9 100644
--- a/asciidoc/use/cachefileset.adoc
+++ b/asciidoc/use/cachefileset.adoc
@@ -17,38 +17,32 @@
under the License.
////
-Constructs an ant fileset consisting of artifacts in ivy cache for a configuration (*__since 1.2__*).
-
+Constructs an Ant `fileset consisting` of artifacts in Ivy's cache for a configuration (*__since 1.2__*).
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
-does not rely on retrieve, because built fileset is made of artifacts direcly in ivy cache.
-
+does not rely on retrieve, because built fileset is made of artifacts direcly 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).
-
-
-Built fileset is registered in ant with a given id, and can thus be used like any other ant fileset using
-refid.
+more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more).
+Built `fileset` is registered in Ant with a given id, and can thus be used like any other Ant `fileset` using
+`refid`.
== Limitation
-A fileset, in Ant, requires a base directory from within which the files are included/excluded. The cachefileset task, in Ivy, internally tries to determine a common base directory across all the resolved artifacts' files that have been downloaded in the Ivy repository cache(s). Given that Ivy can be configured to consist multiple repository caches and each one can potentially be on a different filesystem root, there are times, when cachefileset cannot determine a common base directory for these resolved artifacts. The cachefileset throws an exception in such cases.
-
+A `fileset`, in Ant, requires a base directory from within which the files are included/excluded. The `cachefileset` task, in Ivy, internally tries to determine a common base directory across all the resolved artifacts' files that have been downloaded in the Ivy repository cache(s). Given that Ivy can be configured to consist multiple repository caches and each one can potentially be on a different filesystem root, there are times, when `cachefileset` cannot determine a common base directory for these resolved artifacts. The `cachefileset` throws an exception in such cases.
== 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.html[resources] task could be an alternative task to use in certain cases.
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|setid|the id to reference the built fileset|Yes
-|conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
-|type|comma separated list of artifact types to accept in the path, * for all|No. Defaults to *
-|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, 'ivy.instance' is taken by default.
+|conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called
+|type|comma separated list of artifact types to accept in the path, `*` for all|No. Defaults to `*`
+|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default.
|=======
-
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/cachepath.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/cachepath.adoc b/asciidoc/use/cachepath.adoc
index 1167de7..8ed8e9c 100644
--- a/asciidoc/use/cachepath.adoc
+++ b/asciidoc/use/cachepath.adoc
@@ -17,63 +17,49 @@
under the License.
////
-Constructs an ant path consisting of artifacts in ivy cache (or origin location with depending on useOrigin setting) for a resolved module configuration.
+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.
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.
-Built path is registered in ant with a given id, and can thus be used like any other ant path using refid.
-
+Built path is registered in ant with a given id, and can thus be used like any other Ant path using `refid`.
+
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|pathid|the id to reference the built path|Yes
-|conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
-|type|comma separated list of artifact types to accept in the path, * for all (*__since 1.2__*)|No. Defaults to *
-|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, 'ivy.instance' is taken by default.
+|conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called
+|type|comma separated list of artifact types to accept in the path, `$$*$$` for all (*__since 1.2__*)|No. Defaults to `*`
+|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default.
|=======
-
-
== Examples
-
[source]
----
-
<cachepath pathid="default.classpath" conf="default" />
-
----
-Construct an ant path composed of all artifacts being part of the default configuration obtained through the last resolve call.
-
+Construct an Ant path composed of all artifacts being part of the default configuration obtained through the last resolve call.
'''
-
-
[source]
----
-
<cachepath pathid="default.classpath" conf="default" useOrigin="true" />
-
----
Same as before but will use the original location for local artifacts, and the cache location for other artifacts.
-
'''
-
-
[source]
----
-
<ivy:cachepath organisation="emma" module="emma" revision="2.0.4217" inline="true" conf="ant" pathid="emma.classpath"/>
<taskdef resource="emma_ant.properties" classpathref="emma.classpath" />
-
----
-Resolves the emma module in version 2.0.4217, constructs an ant path with the corresponding artifacts, and then define the emma tasks using this path.
+Resolves the Emma module in version 2.0.4217, constructs an Ant path with the corresponding artifacts, and then define the Emma tasks using this path.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/checkdepsupdate.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/checkdepsupdate.adoc b/asciidoc/use/checkdepsupdate.adoc
index 065f316..1ed6ce7 100644
--- a/asciidoc/use/checkdepsupdate.adoc
+++ b/asciidoc/use/checkdepsupdate.adoc
@@ -21,24 +21,19 @@ Display dependency updates on the console. This task can also show transitive de
This is a link:../use/postresolvetask.html[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).
-
+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).
== Attributes
-
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|revisionToCheck|target revision to check|No. Defaults to 'latest.integration'
-|download|specify if artifact should be downloaded when new updates are found|No. Defaults to 'false'
-|checkIfChanged|When set to true, the resolve will compare the result with the last resolution done on this module, with those configurations in order to define the property ivy.deps.changed. Put it to false may provides slightly better performance.|No, default to 'false'
-|showTransitive|set to true if you want to see potential updates on transitive dependencies|No. Defaults to 'false'
+|revisionToCheck|target revision to check|No. Defaults to `latest.integration`
+|download|specify if artifact should be downloaded when new updates are found|No. Defaults to `false`
+|checkIfChanged|When set to `true`, the resolve will compare the result with the last resolution done on this module, with those configurations in order to define the property ivy.deps.changed. Put it to false may provides slightly better performance.|No, default to `false`
+|showTransitive|set to `true` if you want to see potential updates on transitive dependencies|No. Defaults to `false`
|=======
-
-
== Example
Suppose we have two dependencies one called __mydep__ in revision 1.0 and one called __myotherdependency__ in revision 2.0.
@@ -48,40 +43,31 @@ Then:
[source]
----
-
<checkdepsupdate />
-
----
will display the following updates in the console:
[source]
----
-
Dependencies updates available :
mycompany#mydep 1.0 -> 2.0
mycompany#myotherdependency 2.0 -> 2.2
-
----
Same example with transitive dependencies :
[source]
----
-
<checkdepsupdate showTransitive="true" />
-
----
will display the following updates in the console:
[source]
----
-
Dependencies updates available :
mycompany#mydep 1.0 -> 2.0
mycompany#myotherdependency 2.0 -> 2.2
mycompany##mytransitivedependency (transitive) 2.2 -> 2.4
-
----
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/cleancache.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/cleancache.adoc b/asciidoc/use/cleancache.adoc
index 252e600..e4a0590 100644
--- a/asciidoc/use/cleancache.adoc
+++ b/asciidoc/use/cleancache.adoc
@@ -24,44 +24,33 @@ This task is roughly equivalent to:
[source]
----
-
<delete dir="${ivy.cache.dir}" />
-
----
Using the regular Ant delete task is more flexible, since it allows to specify the files to delete. But it requires an Ivy settings to be loaded, and settings scoping is possible only by using suffixed ant property for the cache directory.
-This task loads the Ivy settings as any other post settings task, and allows easy scoping with the attribute settingsRef.
-
+This task loads the Ivy settings as any other post settings task, and allows easy scoping with the attribute `settingsRef`.
== Attributes
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|settingsRef|A reference to the ivy settings that must be used by this task|No, 'ivy.instance' is taken by default.
+|settingsRef|A reference to the ivy settings that must be used by this task|No. Defaults to `ivy.instance`.
|=======
-
== Examples
-
[source]
----
-
<ivy:cleancache />
-
----
-Cleans the cache directory as defined in the loaded settings (by default ~/.ivy2/cache)
-
+Cleans the cache directory as defined in the loaded settings (by default `~/.ivy2/cache`)
[source]
----
-
<ivy:cleancache settingsRef="mysettings"/>
-
----
-Cleans the cache directory as defined in the loaded settings identified as 'mysettings'
+Cleans the cache directory as defined in the loaded settings identified as `mysettings`
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/configure.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/configure.adoc b/asciidoc/use/configure.adoc
index 568dd56..7b19738 100644
--- a/asciidoc/use/configure.adoc
+++ b/asciidoc/use/configure.adoc
@@ -17,92 +17,72 @@
under the License.
////
-The configure task is used to configure ivy with an xml settings file.
-
+The `configure` task is used to configure ivy with an xml settings file.
See link:../settings.html[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.
+*__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.
*__since 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.
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|settingsId|The settings id useable in the settingsRef attributes of the ivy task that needs a setting. Note that the ivy tasks will search by default for the settings with the id "ivy.instance", which is the default value.|No, defaults to "ivy.instance"
-|file|path to the settings file to use|No. If a file is provided, url is ignored. If none are provided, then it attempts to find a file at ${ivy.settings.file}, and if this file does not exist, it uses ${ivy.settings.url} *__(since 2.3)__* or a link:../samples/ivysettings-default.xml[default settings file]
+|settingsId|The settings id useable in the `settingsRef` attributes of the Ivy task that needs a setting.|No, defaults to `ivy.instance`
+|file|path to the settings file to use
+.2+|No. If a file is provided, url is ignored. If none are provided, then it attempts to find a file at `${ivy.settings.file}`, and if this file does not exist, it uses `${ivy.settings.url}` *__(since 2.3)__* or a link:../samples/ivysettings-default.xml[default settings file]
|url|url of the settings file to use
-|override|Specify what to do when another settings with the same id has already been loaded.
-* true +
- the current settings will take precedence over any previously defined setting with this id
-* false +
- the current settings will not override a previously defined setting with this id
-* notallowed +
-an error is raised if a settings has already been defined with this id|No, defaults to "notallowed"
-|host|http authentication host|No, unless authentication is required
-|realm|http authentication realm
-|username|http authentication user name
-|passwd|http authentication password
+|override|Specify what to do when another settings with the same id has already been loaded. +
+* `true`: the current settings will take precedence over any previously defined setting with this id +
+* `false`: the current settings will not override a previously defined setting with this id +
+* `notallowed`: an error is raised if a settings has already been defined with this id|No, defaults to `notallowed`
+|host|HTTP authentication host
+.4+.^|No, unless authentication is required
+|realm|HTTP authentication realm
+|username|HTTP authentication user name
+|passwd|HTTP authentication password
|=======
-
== HTTP Authentication
-If any of the url you use in ivy (especially in dependency resolvers) need http
-authentication, then you have to provide the host, realm, username and passwd
-attributes of the configure task. These settings will then be used in any
-further call to ivy tasks.
-
-
+If any of the url you use in Ivy (especially in dependency resolvers) needs http authentication, then you have to provide the `host`, `realm`, `username` and `passwd` attributes of the configure task. These settings will then be used in any further call to Ivy tasks.
*Since 1.4:*
-It's also possible to configure authentication settings for multiple urls. This can be done with the <credentials> subelements. See the examples for more details.
-
+It's also possible to configure authentication settings for multiple urls. This can be done with the `<credentials>` subelements. See the examples for more details.
== Examples
-
=== Simplest settings
-
[source]
----
<ivy:configure />
----
-Use either ${ivy.settings.file} if it exists, or the link:../samples/ivysettings-default.xml[default settings file]
+Use either `${ivy.settings.file}` if it exists, or the link:../samples/ivysettings-default.xml[default settings file]
=== Configure with a file
-
[source]
----
<ivy:configure file="myconffile.xml" />
----
-
=== Configure with an url
-
[source]
----
<ivy:configure url="http://mysite.com/myconffile.xml" />
----
-
-==== Configure multiple URLs which require autentication
-
+=== Configure multiple URLs which require autentication
[source]
----
-
<ivy:configure file="path/to/my/ivysettings.xml">
<credentials host="myhost.com" realm="My Realm" username="myuser" passwd="mypasswd" />
<credentials host="yourhost.com" realm="Your Realm" username="myuser" passwd="myotherpasswd" />
</ivy:configure>
-
----
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/convertmanifest.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/convertmanifest.adoc b/asciidoc/use/convertmanifest.adoc
index 5cde741..6bd6dd7 100644
--- a/asciidoc/use/convertmanifest.adoc
+++ b/asciidoc/use/convertmanifest.adoc
@@ -17,26 +17,22 @@
under the License.
////
-*__since 2.3__* Convert a MANIFEST.MF into an ivy.ml file
+*__since 2.3__* Convert a `MANIFEST.MF` into an `ivy.ml` file
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|manifest|the location of the MANIFEST.MF to convert|Yes
-|ivyFile|the location of the ivy.xml file to generate|Yes
+|manifest|the location of the `MANIFEST.MF` to convert|Yes
+|ivyFile|the location of the `ivy.xml` file to generate|Yes
|=======
-
-
== Examples
-
[source]
----
-
<ivy:convertmanifest manifest="META-INF/MANIFEST.MF" ivyFile="ivy.xml" />
-
----
-Just converts a manifest into an ivy.xml file.
+Just converts a manifest into an `ivy.xml` file.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/convertpom.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/convertpom.adoc b/asciidoc/use/convertpom.adoc
index 82d1c34..8f7e3cc 100644
--- a/asciidoc/use/convertpom.adoc
+++ b/asciidoc/use/convertpom.adoc
@@ -17,8 +17,9 @@
under the License.
////
-*__since 2.1__* Convert pom.xml into an ivy.xml
+*__since 2.1__* Convert `pom.xml` into an `ivy.xml`
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
@@ -27,16 +28,11 @@
|ivyFile|the location of the ivy.xml to generate|Yes
|=======
-
-
== Examples
-
[source]
----
-
<ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml" />
-
----
Just convert an pom.xml file into an ivy.xml.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/deliver.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/deliver.adoc b/asciidoc/use/deliver.adoc
index 10cc7ea..579f405 100644
--- a/asciidoc/use/deliver.adoc
+++ b/asciidoc/use/deliver.adoc
@@ -31,100 +31,70 @@ Finally, in the resolved ivy file, dynamic revisions are replaced by the static
*__since 1.3__* The replacement of dynamic revisions by static ones can be turned off, so that dynamic revisions are kept in the ivy file. This is an exception to the recommended standard that published module descriptors be fully resolved, so use it with caution.
-
-== do recursive delivery
+== Recursive delivery
This is done only if a deliver target is given to the deliver task.
-If a deliver target is set, then it is called (via an antcall) for each dependency which has not a suffisant status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done.
+If a deliver target is set, then it is called (via an `antcall`) for each dependency which has not a suffisant status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done.
If you deliver a milestone or a release revision, deliver target will be called with each integration dependency.
The deliver target is called with the following properties available:
-
-
-* dependency.name +
-the name of the dependency to recursively deliver
-
-* dependency.published.status +
-the status to which the dependency should be delivered
-* dependency.published.version +
-the revision to which the dependency should be delivered
-
-* dependency.version +
-the revision of the dependency that should be delivered (the one that was retrieved during last resolve)
-
-Both
-[source]
-----
-dependency.published.status
-----
-
-and
-[source]
-----
-dependency.published.version
-----
+* `dependency.name`: the name of the dependency to recursively deliver
+* `dependency.published.status`: the status to which the dependency should be delivered
+* `dependency.published.version`: the revision to which the dependency should be delivered
+* `dependency.version`: the revision of the dependency that should be delivered (the one that was retrieved during last resolve)
-can be either asked to the user through ant input tasks (default behaviour), or be always the same for the whole recursive delivery process if the following properties are set:
+Both `dependency.published.status` and `dependency.published.version` can be either asked to the user through Ant input tasks (default behaviour), or be always the same for the whole recursive delivery process if the following properties are set:
+* `recursive.delivery.status`: set to the status to which all dependencies requiring to be delivered will be
+* `recursive.delivery.version`: set to the version to which all dependencies requiring to be delivered will be
-* recursive.delivery.status +
-set to the status to which all dependencies requiring to be delivered will be
-
-* recursive.delivery.version +
-set to the version to which all dependencies requiring to be delivered will be
-
-
-Usually the deliver target itself triggers an another ant build (using ant task) even if this is up to you to decide.
-
-The delivered ivy file will update its dependency revisions with those given here.
+Usually the deliver target itself triggers an another Ant build (using the `ant` task) even if this is up to you to decide.
+The delivered ivy file will update its dependency revisions with those given here.
== 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 explictly? 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.html[publish] task. So, when shall the deliver task be called explictly? 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, ...).
It can also be useful if you want to trigger a recursive delivery and then ensure that you get the recursively delivered modules as dependencies. In this case your build order may look like this:
-- ivy:configure
-- ivy:resolve
-- ivy:deliver with recursive delivery
-- ivy:resolve again with the ivy file generated by the recursive delivery
+
+- `ivy:configure`
+- `ivy:resolve`
+- `ivy:deliver` with recursive delivery
+- `ivy:resolve` again with the ivy file generated by the recursive delivery
- do your build stuff (compile, jar, whatever)
-- ivy:publish
-
+- `ivy:publish`
+
+== Attributes
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|deliverpattern|the pattern to use for ivy file delivery|No. Defaults to ${ivy.deliver.ivy.pattern}
-|pubrevision|the revision to use for the publication|No. Defaults to ${ivy.deliver.revision} if set, or the revision resolved if set, or a timestamp
-|pubbranch|the branch to use for the publication|No. Defaults to ${ivy.deliver.branch} if set, or the branch resolved if set, or nothing (branch info won't be updated)
-|pubdate|the publication date to use for the publication. This date should be either 'now', or a date given with the following pattern: yyyyMMddHHmmss|No. Defaults to 'now'
-|status|the status to use for the publication|No. Defaults to ${ivy.status}
+|deliverpattern|the pattern to use for ivy file delivery|No. Defaults to `${ivy.deliver.ivy.pattern}`
+|pubrevision|the revision to use for the publication|No. Defaults to `${ivy.deliver.revision}` if set, or the revision resolved if set, or a timestamp
+|pubbranch|the branch to use for the publication|No. Defaults to `${ivy.deliver.branch}` if set, or the branch resolved if set, or nothing (branch info won't be updated)
+|pubdate|the publication date to use for the publication. This date should be either `now`, or a date given with the following pattern: `yyyyMMddHHmmss`|No. Defaults to `now`
+|status|the status to use for the publication|No. Defaults to `${ivy.status}`
|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 configuration file)
-|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.
-|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, 'ivy.instance' is taken 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 configuration file)
+|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`.
+|settingsRef|A reference to the 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 deliverd file (see the link:../ivyfile/dependency.html[dependency] page for more info about this attribute), false to never generate this attribute *__(since 2.1.0)__*|No. Defaults to true
+|generateRevConstraint|`true` to automatically generate a `revConstraint attribute in the deliverd file (see the link:../ivyfile/dependency.html[dependency] page for more info about this attribute), `false` to never generate this attribute *__(since 2.1.0)__*|No. Defaults to `true`
|=======
-
-
== Example
Deliver an ivy file without the private configurations:
[source]
----
-
-<deliver conf="*(public)" />
-
+<deliver conf="*(public)" />
----
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/dependencytree.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/dependencytree.adoc b/asciidoc/use/dependencytree.adoc
index 81e10a6..75e039e 100644
--- a/asciidoc/use/dependencytree.adoc
+++ b/asciidoc/use/dependencytree.adoc
@@ -21,26 +21,21 @@ 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.
-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).
-
+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).
== Attributes
-
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|showEvicted|specify if evicted modules should be printed|No. Defaults to false
-|conf|a comma separated list of the configurations to take in consideration in the dependency tree|No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
-|haltonfailure|true to halt the build on ivy failure, false to continue|No. Defaults to true
+|showEvicted|specify if evicted modules should be printed|No. Defaults to `false`
+|conf|a comma separated list of the configurations to take in consideration in the dependency tree|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called
+|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 configuration file)
-|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, 'ivy.instance' is taken by default.
-|overwrite|Overwrite the value of the property if it already exist *(since 2.0)*. Before 2.0, the properties were always overwritten.|No, 'false' by default.
+|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, defaults to `ivy.instance`.
+|overwrite|Overwrite the value of the property if it already exist *(since 2.0)*. Before 2.0, the properties were always overwritten.|No, `false` by default.
|=======
-
-
== Example
Suppose we have two dependencies one called __mydep__ in revision 2.0 and one called __myotherdependency__ in revision 2.2.
@@ -50,20 +45,15 @@ Then:
[source]
----
-
<dependencytree />
-
----
will display the following tree in the console:
[source]
----
-
Dependency tree for foobar
+- org#mydep;2.0
\- org#mytransitivedependency;2.2
\- org#myotherdependency;2.2");
-
----
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/findrevision.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/findrevision.adoc b/asciidoc/use/findrevision.adoc
index 84c7849..1bcca9f 100644
--- a/asciidoc/use/findrevision.adoc
+++ b/asciidoc/use/findrevision.adoc
@@ -23,10 +23,8 @@ 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.
If the module is not found the property is not set.
-
== Attributes
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
@@ -34,33 +32,24 @@ If the module is not found the property is not set.
|module|the the name of the module to find|Yes
|branch|the branch of the module to find|No, defaults to the default branch for the given module
|revision|the revision constraint to apply|Yes
-|property|the property to set with the found revision|No, defaults to ivy.revision
-|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, 'ivy.instance' is taken by default.
+|property|the property to set with the found revision|No, defaults to `ivy.revision`
+|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`.
|=======
-
== Examples
-
[source]
----
-
<ivy:findrevision organisation="apache" module="ivy" revision="latest.integration"/>
-
----
-finds the latest version of ivy available in the repository and sets the property ivy.revision according to what was found.
-
+finds the latest version of ivy available in the repository and sets the property `ivy.revision` according to what was found.
'''
-
-
[source]
----
-
<ivy:findrevision organisation="apache" module="ivy" revision="1.0+"/>
-
----
same as above but only with 1.0 sub versions.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/fixdeps.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/fixdeps.adoc b/asciidoc/use/fixdeps.adoc
index fc32a26..3f7ca7a 100644
--- a/asciidoc/use/fixdeps.adoc
+++ b/asciidoc/use/fixdeps.adoc
@@ -18,9 +18,9 @@
////
*__since 2.4__*
-The `fixdeps` task serializes transitively resolved dependencies into an ivy.xml file.
+The `fixdeps` task serializes transitively resolved dependencies into an `ivy.xml` file.
-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 reproductible.
+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 reproductible.
It is especially useful in a very dynamic environment like the link:../osgi.html[OSGi] one.
@@ -28,71 +28,48 @@ In a multi project environment some dependencies still need to be maintained loo
The recommended setup is then to:
-
-* have an `ivy-spec.xml` in your project which specifies the dependencies, with ranges if needed +
-
-* have an Ant target which resolve 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 (svn, git,...). +
-
-* make the entire build workflow based on the resolve of the generated `ivy.xml` +
-
+* have an `ivy-spec.xml` in your project which specifies the dependencies, with ranges if needed
+* have an Ant target which resolve 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 (svn, git,...).
+* 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.
-
== Attributes
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|tofile|The location of the ivy file to generate|Yes
|=======
-
-
== Child elements
-
-
[options="header",cols="15%,50%,35%"]
|=======
|Element|Description|Cardinality
|keep|declares a dependency to keep from being fixed, and keep its original declaration from the original ivy.xml
-These elements takes two attributes:
-* org +
- the organization
-* module +
-the name of the module|0..n
+These elements takes two attributes: +
+* `org`: the organization +
+* `module`: the name of the module|0..n
|=======
-
-
== Examples
-
-
[source]
----
-
<ivy:fixdeps tofile="ivy-fixed.xml" />
-
----
Simple fix of some dependencies.
-
'''
-
-
[source]
----
-
<ivy:fixdeps tofile="ivy-fixed.xml">
<keep org="com.acme" module="mymodule" />
</ivy:fixdeps>
-
----
Fix of the dependencies but keep the dependency on `com.acme#mymodule` as defined in the original ivy.xml.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/25a67d80/asciidoc/use/info.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/use/info.adoc b/asciidoc/use/info.adoc
index 503a93e..1cf7785 100644
--- a/asciidoc/use/info.adoc
+++ b/asciidoc/use/info.adoc
@@ -18,11 +18,11 @@
////
*__since 1.4__*
-The info task ease the access to some essential data contained in an ivy file without performing a dependency resolution.
+The `info` task ease the access to some essential data contained in an Ivy file without performing a dependency resolution.
-The information is retrieved by setting ant properties:
+The information is retrieved by setting Ant properties:
-[options="header",cols="15%,50%"]
+[options="header",cols="30%,50%"]
|=======
|Property|Description
|ivy.organisation|The organisation of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed.
@@ -42,8 +42,6 @@ The information is retrieved by setting ant properties:
|ivy.artifact.__[index]__.extra.__[any extra attribute]__|For each extra attribute of the published artifact, a property is created containing its name. *__(Since 2.2)__*
|=======
-
-
*__since 2.0__*
Since Ivy 2.0 this task has been enhanced to allow you to retrieve information about ivy modules in a repository. Instead of specifying a local ivy file you may specify the organisation, module, revision pattern and (optionally) the branch of the ivy module in the repository you wish to retrieve the information for.
@@ -52,16 +50,14 @@ The revision pattern is what is used when declaring a link:../ivyfile/dependency
If no matching module is found then no property values are set.
-You may now also set the property attribute to change the first part of the property names that are set by this task e.g. if you set the property attribute to 'mymodule' this task will set the ant properties __mymodule.organisation__, __mymodule.module__, __mymodule.revision__ etc.
+You may now also set the property attribute to change the first part of the property names that are set by this task e.g. if you set the property attribute to `mymodule` this task will set the ant properties `mymodule.organisation`, `mymodule.module`, `mymodule.revision` etc.
*__since 2.2__*
Since Ivy 2.2 this task has been enhanced to also retrieve detailed information about the module's published artifacts, as well as the publication time.
-
== Attributes
-
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
@@ -74,18 +70,16 @@ Yes, if you are retrieving information about a module from an ivy repository.
|branch|the branch of the module to find *__(since 2.0)__*|No, defaults to the default branch for the given module if you are retrieving information about a module from an ivy repository.
|revision|the revision constraint to apply *__(since 2.0)__*|No, if you wish to parse an ivy file.
Yes, if you are retrieving information about a module from an ivy repository.
-|property|the name to use as the base of the property names set by this task *__(since 2.0)__*|No, will default to 'ivy' if not set.
-|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, 'ivy.instance' is taken by default.
+|property|the name to use as the base of the property names set by this task *__(since 2.0)__*|No, will default to `ivy` if not set.
+|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`.
|=======
-
== Examples
-Given this ivy.xml file:
+Given this `ivy.xml` file:
[source]
----
-
<ivy-module version="1.0" xmlns:e="http://ant.apache.org/ivy/extra">
<info organisation="apache"
module="info-all"
@@ -107,22 +101,17 @@ Given this ivy.xml file:
<dependency org="org1" name="mod1.2" rev="2.0"/>
</dependencies>
</ivy-module>
-
----
-
[source]
----
-
<ivy:info file="${basedir}/path/to/ivy.xml" />
-
----
-Parses ${basedir}/path/to/ivy.xml and set properties as described above accordingly:
+Parses `+++${basedir}/path/to/ivy.xml+++` and set properties as described above accordingly:
[source]
----
-
ivy.organisation=apache
ivy.module=info-all
ivy.branch=trunk
@@ -141,32 +130,26 @@ ivy.artifact.2.type=jar
ivy.artifact.2.ext=jar
ivy.artifact.2.conf=default
ivy.artifact.2.extra.data=client
-
----
Given the same ivy module in a repository:
[source]
----
-
<ivy:info organisation="apache" module="info-all" revision="1.0" />
-
----
will set the exact same set of properties as above. Using:
[source]
----
-
<ivy:info organisation="apache" module="info-all" revision="1.0" property="infotest"/>
-
----
will set:
[source]
----
-
infotest.organisation=apache
infotest.module=info-all
infotest.branch=trunk
@@ -185,6 +168,4 @@ infotest.artifact.2.type=jar
infotest.artifact.2.ext=jar
infotest.artifact.2.conf=default
infotest.artifact.2.extra.data=client
-
----
-