You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by ja...@apache.org on 2017/06/19 01:59:08 UTC
[25/29] ant-ivy git commit: Initial auto-converted .adoc files from
xooki2asciidoc convertor
Initial auto-converted .adoc files from xooki2asciidoc convertor
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/22bdffb9
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/22bdffb9
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/22bdffb9
Branch: refs/heads/master
Commit: 22bdffb96dd29d98e2eb7b7f9f3a48a46ccc86ce
Parents: 32296ea
Author: Jaikiran Pai <ja...@gmail.com>
Authored: Thu Jun 15 18:37:16 2017 +0530
Committer: Jaikiran Pai <ja...@gmail.com>
Committed: Fri Jun 16 09:57:06 2017 +0530
----------------------------------------------------------------------
asciidoc/ant.adoc | 182 ++++
asciidoc/bestpractices.adoc | 116 +++
asciidoc/compatibility.adoc | 30 +
asciidoc/concept.adoc | 404 ++++++++
asciidoc/configuration.adoc | 3 +
asciidoc/configuration/caches.adoc | 3 +
asciidoc/configuration/caches/cache.adoc | 3 +
asciidoc/configuration/caches/ttl.adoc | 3 +
asciidoc/configuration/classpath.adoc | 4 +
asciidoc/configuration/conf.adoc | 3 +
asciidoc/configuration/conflict-managers.adoc | 4 +
asciidoc/configuration/include.adoc | 4 +
asciidoc/configuration/latest-strategies.adoc | 4 +
asciidoc/configuration/lock-strategies.adoc | 3 +
asciidoc/configuration/macrodef.adoc | 4 +
asciidoc/configuration/macrodef/attribute.adoc | 3 +
asciidoc/configuration/module.adoc | 4 +
asciidoc/configuration/modules.adoc | 4 +
asciidoc/configuration/namespace.adoc | 4 +
asciidoc/configuration/namespace/dest.adoc | 3 +
.../configuration/namespace/fromtosystem.adoc | 3 +
asciidoc/configuration/namespace/rule.adoc | 3 +
asciidoc/configuration/namespace/src.adoc | 3 +
asciidoc/configuration/namespaces.adoc | 4 +
asciidoc/configuration/outputters.adoc | 4 +
asciidoc/configuration/parsers.adoc | 4 +
asciidoc/configuration/properties.adoc | 4 +
asciidoc/configuration/property.adoc | 4 +
asciidoc/configuration/resolvers.adoc | 4 +
asciidoc/configuration/status.adoc | 4 +
asciidoc/configuration/statuses.adoc | 4 +
asciidoc/configuration/triggers.adoc | 3 +
asciidoc/configuration/typedef.adoc | 4 +
asciidoc/configuration/version-matchers.adoc | 4 +
asciidoc/dev.adoc | 123 +++
asciidoc/dev/makerelease.adoc | 318 ++++++
asciidoc/extend.adoc | 35 +
asciidoc/images/ant-project-logo.gif | Bin 0 -> 7577 bytes
asciidoc/images/ant-project-logo.svg | 951 ++++++++++++++++++
asciidoc/images/apache-incubator-logo.png | Bin 0 -> 6205 bytes
asciidoc/images/apache-incubator.svg | 44 +
asciidoc/images/bullet.gif | Bin 0 -> 193 bytes
asciidoc/images/closed.gif | Bin 0 -> 141 bytes
asciidoc/images/discovery.gif | Bin 0 -> 362 bytes
asciidoc/images/downloaded.gif | Bin 0 -> 104 bytes
asciidoc/images/error.gif | Bin 0 -> 605 bytes
asciidoc/images/evicted.gif | Bin 0 -> 215 bytes
asciidoc/images/grippie.png | Bin 0 -> 162 bytes
asciidoc/images/hibgraph-small.png | Bin 0 -> 9042 bytes
asciidoc/images/hibgraph.png | Bin 0 -> 51535 bytes
asciidoc/images/hibgraph.svg | 173 ++++
asciidoc/images/ivy-book.png | Bin 0 -> 14182 bytes
asciidoc/images/ivy-demo.png | Bin 0 -> 24544 bytes
asciidoc/images/ivy-dl-1.4.1.png | Bin 0 -> 10892 bytes
asciidoc/images/ivy-dl-2.0.0-alpha-1.png | Bin 0 -> 12149 bytes
asciidoc/images/ivy-dl.xcf | Bin 0 -> 29498 bytes
asciidoc/images/ivy-forum.png | Bin 0 -> 10441 bytes
asciidoc/images/ivy-lierre.png | Bin 0 -> 15263 bytes
asciidoc/images/ivy-publish-fc.odg | Bin 0 -> 11126 bytes
asciidoc/images/ivy-publish-fc.png | Bin 0 -> 20111 bytes
asciidoc/images/ivy-publish-fc.svg | 337 +++++++
asciidoc/images/ivy-terminology.odg | Bin 0 -> 22331 bytes
asciidoc/images/ivy-terminology.png | Bin 0 -> 70573 bytes
asciidoc/images/ivy-terminology.svg | 419 ++++++++
asciidoc/images/ivyfile-small.png | Bin 0 -> 16328 bytes
asciidoc/images/logo.png | Bin 0 -> 8772 bytes
asciidoc/images/main-tasks.odg | Bin 0 -> 12386 bytes
asciidoc/images/main-tasks.png | Bin 0 -> 32995 bytes
asciidoc/images/main-tasks.svg | 82 ++
asciidoc/images/open.gif | Bin 0 -> 151 bytes
asciidoc/images/report-small.png | Bin 0 -> 16751 bytes
asciidoc/images/searched.gif | Bin 0 -> 229 bytes
asciidoc/images/warning.png | Bin 0 -> 762 bytes
asciidoc/images/xooki-edit-small.png | Bin 0 -> 30143 bytes
asciidoc/images/xooki-edit.png | Bin 0 -> 52706 bytes
asciidoc/images/xooki-toolbar.png | Bin 0 -> 6539 bytes
asciidoc/images/yed-step1.jpg | Bin 0 -> 3077 bytes
asciidoc/images/yed-step2.jpg | Bin 0 -> 15150 bytes
asciidoc/images/yed-step3-2.jpg | Bin 0 -> 3816 bytes
asciidoc/images/yed-step3.jpg | Bin 0 -> 21662 bytes
asciidoc/images/yed-step4.jpg | Bin 0 -> 10558 bytes
asciidoc/images/yed-step5.jpg | Bin 0 -> 31309 bytes
asciidoc/images/yed-step6.jpg | Bin 0 -> 21240 bytes
asciidoc/images/yed-step7.jpg | Bin 0 -> 51973 bytes
asciidoc/index.adoc | 69 ++
asciidoc/install.adoc | 74 ++
asciidoc/ivyfile.adoc | 126 +++
asciidoc/ivyfile/artifact-conf.adoc | 19 +
asciidoc/ivyfile/artifact-exclude-conf.adoc | 19 +
asciidoc/ivyfile/artifact-exclude.adoc | 49 +
asciidoc/ivyfile/artifact.adoc | 94 ++
asciidoc/ivyfile/conf.adoc | 62 ++
asciidoc/ivyfile/configurations.adoc | 190 ++++
asciidoc/ivyfile/conflict.adoc | 35 +
asciidoc/ivyfile/conflicts.adoc | 51 +
asciidoc/ivyfile/dependencies.adoc | 52 +
asciidoc/ivyfile/dependency-artifact-conf.adoc | 17 +
asciidoc/ivyfile/dependency-artifact.adoc | 100 ++
asciidoc/ivyfile/dependency-conf.adoc | 33 +
asciidoc/ivyfile/dependency-include-conf.adoc | 17 +
asciidoc/ivyfile/dependency-include.adoc | 46 +
asciidoc/ivyfile/dependency.adoc | 409 ++++++++
asciidoc/ivyfile/description.adoc | 22 +
asciidoc/ivyfile/exclude.adoc | 24 +
asciidoc/ivyfile/extends.adoc | 40 +
asciidoc/ivyfile/include.adoc | 57 ++
asciidoc/ivyfile/info.adoc | 39 +
asciidoc/ivyfile/ivyauthor.adoc | 20 +
asciidoc/ivyfile/license.adoc | 19 +
asciidoc/ivyfile/manager.adoc | 34 +
asciidoc/ivyfile/mapped.adoc | 20 +
asciidoc/ivyfile/override.adoc | 29 +
asciidoc/ivyfile/publications.adoc | 34 +
asciidoc/ivyfile/repository.adoc | 23 +
asciidoc/js/jquery.pack.js | 1 +
asciidoc/js/jquery.treeview.js | 239 +++++
asciidoc/moreexamples.adoc | 33 +
asciidoc/osgi.adoc | 44 +
asciidoc/osgi/eclipse-plugin.adoc | 88 ++
asciidoc/osgi/osgi-mapping.adoc | 242 +++++
asciidoc/osgi/sigil.adoc | 37 +
asciidoc/osgi/standard-osgi.adoc | 46 +
asciidoc/osgi/target-platform.adoc | 48 +
asciidoc/principle.adoc | 64 ++
asciidoc/reference.adoc | 38 +
asciidoc/release-notes.adoc | 377 ++++++++
asciidoc/resolver/bintray.adoc | 53 +
asciidoc/resolver/chain.adoc | 87 ++
asciidoc/resolver/dual.adoc | 29 +
asciidoc/resolver/filesystem.adoc | 77 ++
asciidoc/resolver/ibiblio.adoc | 70 ++
asciidoc/resolver/ivyrep.adoc | 47 +
asciidoc/resolver/jar.adoc | 76 ++
asciidoc/resolver/mirrored.adoc | 83 ++
asciidoc/resolver/obr.adoc | 62 ++
asciidoc/resolver/osgiagg.adoc | 43 +
asciidoc/resolver/packager.adoc | 351 +++++++
asciidoc/resolver/sftp.adoc | 133 +++
asciidoc/resolver/ssh.adoc | 92 ++
asciidoc/resolver/updatesite.adoc | 52 +
asciidoc/resolver/url.adoc | 55 ++
asciidoc/resolver/vfs.adoc | 46 +
asciidoc/running.adoc | 11 +
asciidoc/samples/apache-hello-ivy-default.html | 371 +++++++
asciidoc/samples/build-install.xml | 72 ++
asciidoc/samples/build.xml | 151 +++
.../samples/commons-lang1.0-dep-report-part.jpg | Bin 0 -> 12087 bytes
asciidoc/samples/eclipse-plugin/build.xml | 77 ++
asciidoc/samples/eclipse-plugin/ivy.xml | 39 +
.../eclipse-plugin/ivysettings.properties | 21 +
asciidoc/samples/eclipse-plugin/ivysettings.xml | 36 +
.../samples/hibernate3.0-dep-report-part.jpg | Bin 0 -> 35112 bytes
asciidoc/samples/ivy-doc.xsl | 281 ++++++
asciidoc/samples/ivy-report.css | 279 ++++++
asciidoc/samples/ivy-sample-xslt.xml | 101 ++
asciidoc/samples/ivy-sample.xml | 100 ++
asciidoc/samples/ivy-style.css | 160 ++++
asciidoc/samples/ivysettings-default.xml | 24 +
.../jayasoft-ivyrep-example-default.html | 371 +++++++
.../samples/jayasoft-ivyrep-example-default.jpg | Bin 0 -> 12564 bytes
.../projects-dependencies-graph-small.jpg | Bin 0 -> 18280 bytes
.../samples/projects-dependencies-graph.jpg | Bin 0 -> 53526 bytes
asciidoc/samples/standard-osgi/build.xml | 83 ++
asciidoc/samples/standard-osgi/ivy.xml | 24 +
asciidoc/samples/standard-osgi/ivysettings.xml | 34 +
.../org.apache.ivy.sample.standard-osgi.bnd | 18 +
asciidoc/samples/target-platform/build.xml | 56 ++
asciidoc/samples/target-platform/ivy.xml | 24 +
.../samples/target-platform/ivysettings.xml | 33 +
asciidoc/settings.adoc | 131 +++
asciidoc/settings/caches.adoc | 64 ++
asciidoc/settings/caches/cache.adoc | 65 ++
asciidoc/settings/caches/ttl.adoc | 40 +
asciidoc/settings/classpath.adoc | 55 ++
asciidoc/settings/conflict-managers.adoc | 61 ++
asciidoc/settings/credentials.adoc | 18 +
asciidoc/settings/include.adoc | 73 ++
asciidoc/settings/latest-strategies.adoc | 80 ++
asciidoc/settings/lock-strategies.adoc | 34 +
asciidoc/settings/macrodef.adoc | 158 +++
asciidoc/settings/macrodef/attribute.adoc | 18 +
asciidoc/settings/module.adoc | 109 +++
asciidoc/settings/modules.adoc | 23 +
asciidoc/settings/namespace.adoc | 111 +++
asciidoc/settings/namespace/dest.adoc | 43 +
asciidoc/settings/namespace/fromtosystem.adoc | 17 +
asciidoc/settings/namespace/rule.adoc | 19 +
asciidoc/settings/namespace/src.adoc | 18 +
asciidoc/settings/namespaces.adoc | 30 +
asciidoc/settings/outputters.adoc | 43 +
asciidoc/settings/parsers.adoc | 29 +
asciidoc/settings/properties.adoc | 24 +
asciidoc/settings/property.adoc | 58 ++
asciidoc/settings/resolvers.adoc | 146 +++
asciidoc/settings/settings.adoc | 40 +
asciidoc/settings/signers.adoc | 78 ++
asciidoc/settings/status.adoc | 19 +
asciidoc/settings/statuses.adoc | 50 +
asciidoc/settings/triggers.adoc | 551 +++++++++++
asciidoc/settings/typedef.adoc | 20 +
asciidoc/settings/version-matchers.adoc | 121 +++
asciidoc/standalone.adoc | 171 ++++
asciidoc/style/ant.css | 50 +
asciidoc/style/color.css | 159 +++
asciidoc/style/ivy-ref.css | 84 ++
asciidoc/style/nav.css | 28 +
asciidoc/style/print-style.css | 299 ++++++
asciidoc/style/shell.css | 38 +
asciidoc/style/style.css | 372 +++++++
asciidoc/style/tree.css | 53 +
asciidoc/terminology.adoc | 155 +++
asciidoc/textual.adoc | 115 +++
asciidoc/toc.json | 957 +++++++++++++++++++
asciidoc/tutorial.adoc | 46 +
asciidoc/tutorial/build-repository.adoc | 44 +
.../tutorial/build-repository/advanced.adoc | 136 +++
asciidoc/tutorial/build-repository/basic.adoc | 122 +++
asciidoc/tutorial/conf.adoc | 204 ++++
asciidoc/tutorial/defaultconf.adoc | 306 ++++++
asciidoc/tutorial/dependence.adoc | 255 +++++
asciidoc/tutorial/dual.adoc | 140 +++
asciidoc/tutorial/log/chained-resolvers.txt | 38 +
asciidoc/tutorial/log/configurations-lib.txt | 72 ++
asciidoc/tutorial/log/configurations-runcc.txt | 46 +
asciidoc/tutorial/log/configurations-runhm.txt | 32 +
.../tutorial/log/dependence-depending-2.txt | 40 +
asciidoc/tutorial/log/dependence-depending.txt | 40 +
.../tutorial/log/dependence-standalone-2.txt | 36 +
asciidoc/tutorial/log/dependence-standalone.txt | 43 +
asciidoc/tutorial/log/dual.txt | 48 +
asciidoc/tutorial/log/hello-ivy-1.txt | 69 ++
asciidoc/tutorial/log/hello-ivy-2.txt | 32 +
asciidoc/tutorial/log/install-deps.txt | 249 +++++
asciidoc/tutorial/log/install-namespace.txt | 37 +
asciidoc/tutorial/log/install.txt | 37 +
.../tutorial/log/multi-project-find-antp.txt | 17 +
.../tutorial/log/multi-project-general-antp.txt | 8 +
.../log/multi-project-general-publishall.txt | 337 +++++++
.../tutorial/log/myrepository-content-deps.txt | 13 +
.../log/myrepository-content-namespace.txt | 10 +
asciidoc/tutorial/log/myrepository-content.txt | 10 +
asciidoc/tutorial/multiple.adoc | 156 +++
asciidoc/tutorial/multiproject.adoc | 298 ++++++
asciidoc/tutorial/start.adoc | 109 +++
asciidoc/use/artifactproperty.adoc | 57 ++
asciidoc/use/artifactreport.adoc | 82 ++
asciidoc/use/buildlist.adoc | 143 +++
asciidoc/use/buildnumber.adoc | 137 +++
asciidoc/use/buildobr.adoc | 93 ++
asciidoc/use/cachefileset.adoc | 37 +
asciidoc/use/cachepath.adoc | 61 ++
asciidoc/use/checkdepsupdate.adoc | 69 ++
asciidoc/use/cleancache.adoc | 49 +
asciidoc/use/configure.adoc | 90 ++
asciidoc/use/convertmanifest.adoc | 24 +
asciidoc/use/convertpom.adoc | 24 +
asciidoc/use/deliver.adoc | 112 +++
asciidoc/use/dependencytree.adoc | 51 +
asciidoc/use/findrevision.adoc | 48 +
asciidoc/use/fixdeps.adoc | 80 ++
asciidoc/use/info.adoc | 172 ++++
asciidoc/use/install.adoc | 42 +
asciidoc/use/listmodules.adoc | 56 ++
asciidoc/use/makepom.adoc | 131 +++
asciidoc/use/postresolvetask.adoc | 105 ++
asciidoc/use/publish.adoc | 77 ++
asciidoc/use/report.adoc | 80 ++
asciidoc/use/repreport.adoc | 109 +++
asciidoc/use/resolve.adoc | 308 ++++++
asciidoc/use/resources.adoc | 105 ++
asciidoc/use/retrieve.adoc | 257 +++++
asciidoc/use/settings.adoc | 122 +++
asciidoc/use/var.adoc | 28 +
asciidoc/yed.adoc | 46 +
274 files changed, 20776 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/ant.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ant.adoc b/asciidoc/ant.adoc
new file mode 100644
index 0000000..92b75c3
--- /dev/null
+++ b/asciidoc/ant.adoc
@@ -0,0 +1,182 @@
+
+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 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).
+
+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._
+
+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.
+
+If you use an ant version lower than 1.5.1, you can not use the ivy tasks... you should then call ivy as any external program.
+
+== Calling ivy from ant: first steps
+
+Once your build file is ok to call ivy tasks, the simplest way to use ivy is to call the ivy retrieve task with no parameters:
+
+[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 />
+
+ <ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}" />
+
+ <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. +
+
+
+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
+ivy.distrib.dir = ${ivy.project.dir}/distrib
+
+ivy.resolver.default.check.modified = false
+ivy.default.always.check.exact.revision = true
+
+ivy.configurations = *
+ivy.resolve.default.type.filter = *
+ivy.status = integration
+ivy.dep.file = ivy.xml
+ivy.settings.file = ivysettings.xml
+ivy.retrieve.pattern = ${ivy.lib.dir}/[artifact]-[revision].[ext]
+ivy.deliver.ivy.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
+ivy.publish.src.artifacts.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
+
+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.
+
+
+== 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 +
+
+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).
+
+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:
+
+
+[source]
+----
+
+<project xmlns:ivy="antlib:org.apache.ivy.ant" name="sample" default="resolve">
+
+ <target name="resolve">
+ <ivy:configure file="../ivysettings.xml" />
+
+ <ivy:resolve file="my-ivy.xml" conf="default, myconf" />
+
+ </target>
+
+ <target name="retrieve-default" depends="resolve">
+ <ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default" />
+ </target>
+
+ <target name="retrieve-myconf" depends="resolve">
+ <ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf" />
+ </target>
+
+ <target name="retrieve-all" depends="resolve">
+ <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" />
+ </target>
+
+ <target name="deliver" depends="retrieve-all">
+ <ivy:deliver deliverpattern="distrib/[artifact]-[revision].[ext]"
+ pubrevision="1.1b4" pubdate="20050115123254" status="milestone" />
+ </target>
+
+ <target name="publish" depends="deliver">
+ <ivy:publish resolver="internal"
+ artifactspattern="distrib/[artifact]-[revision].[ext]"
+ pubrevision="1.1b4" />
+ </target>
+</project>
+
+----
+
+All ivy tasks are documented in the following pages.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/bestpractices.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/bestpractices.adoc b/asciidoc/bestpractices.adoc
new file mode 100644
index 0000000..f65296a
--- /dev/null
+++ b/asciidoc/bestpractices.adoc
@@ -0,0 +1,116 @@
+
+Here are some recommendations and best practices we have gathered throughout our experience and consultancies with our customers.
+
+
+== Add module descriptors for all your modules
+
+In Ivy world, module descriptors are ivy files, which are basically simple xml files describing both what the module produces as artifacts and its dependencies.
+
+It is a good practice to write or download module descriptors for all the modules involved in your development, even for your third party dependencies, and even if they don't provide such module descriptors themselves.
+
+First, it will seem like extra work and require time. But when you have several modules using the same third party library, then you will only need to add one line to your ivy file to get this library and all its own dependencies that you really need (if you have good module descriptors in your repository, especially with the use of module link:concept.html#configurations[configurations]). It will also be very helpful when you want to upgrade a dependency. One single change in your module ivy file and you will get the updated version with its updated (or not) dependencies.
+
+Therefore we recommend adding ivy files for all the modules in your repository. You can even enforce this rule by setting the descriptor attribute to required on your link:settings/resolvers.html[resolvers]. Hence you shouldn't need to use the dependency artifact inclusion/exclusion/specification feature of Ivy, which should only be used in very specific cases.
+
+
+== Use your own enterprise repository
+
+This is usually not a valid recommendation for open source projects, but for the enterprise world we strongly suggest to avoid relying on a public repository like maven ibiblio or ivyrep. Why? Well, there are a couple of reasons:
+
+
+* control +
+ The main problem with these kinds of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fix it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hides the one on the public repository, but this makes repository browsing and maintenance cumbersome.
+Even more problematic is the possible updates of the repository. We know that versions published in such repositories should be stable and not be updated, but we also frequently see that a module descriptor is buggy, or an artifact corrupted. We even see sometimes a new version published with the same name as the preceding one because the previous one was simply badly packaged. This can occur even to the best; it occurred to us with Ivy 1.2 :-) But then we decided to publish the new version with a different name, 1.2a. But if the repository manager allows such updates, this means that what worked before can break. It can thus break your build reproducibility.
+
+* reliability +
+ The Maven repository is not particularly well known for its reliability (we often experience major slow downs or even complete failures of the site), and ivyrep is only supported by a small company (yes we are only a small company!). So slow down and site hangs occur also. And if the repository you rely on is down, this can cause major slow downs in your development or release process.
+
+* accuracy +
+ A public repository usually contains much more than what you actually need. Is this a problem? We think so. We think that in an enterprise environment the libraries you use should step through some kind of validation process before being used in every projects of your company. And what better way to do so? Setup an enterprise repository with only the libraries you actually want to use. This will not only ensure better quality for your application dependencies, but help to have the same versions everywhere, and even help when declaring your module dependencies, if you use a tool like IvyDE, the code completion will only show relevant information about your repository, with only the libraries you actually want to see.
+
+* security +
+ The artifacts you download from a module repository are often executable, and are thus a security concern. Imagine a hacker replacing commons-lang by another version containing a virus? If you rely on a public repository to build your software, you expose it to a security risk. You can read more about that in this link:http://www.fortifysoftware.com/servlet/downloads/public/fortify_attacking_the_build.pdf[Forrester article].
+
+Note that using an enterprise repository doesn't mean you have to build it entirely by hand. Ivy features an link:use/install.html[install] task which can be used to install modules from one repository to another one, so it can be used to selectively install modules from a public repository to your enterprise repository, where you will then be able to ensure control, reliability and accuracy.
+
+
+== Always use patterns with at least organisation and module
+
+Ivy is very flexible and can accomodate a lot of existing repositories, using the concept of link:concept.html#pattern[patterns]. But if your repository doesn't exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like link:use/install.html[install] or link:use/repreport.html[repreport].
+
+
+== Public ivysettings.xml with public repositories
+
+If you create a public repository, provide a URL to the link:settings.html[ivysettings.xml] file. It's pretty easy to do, and if someone wants to leverage your repository, he will just have to load it with link:use/settings.html[settings] with the URL of your ivysettings.xml file, or link:configuration/include.html[include] it in its own configuration file, which makes it really easy to combine several public repositories.
+
+
+== Dealing with integration versions
+
+Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.
+
+If you follow the continuous integration paradigm across modules, these integration versions can be produced by a continuous integration server, very frequently.
+
+So, how can you deal with these, possibly numerous, integration versions?
+
+There are basically two ways to deal with them, both ways being supported by Ivy:
+
+
+* use a naming convention like a special suffix +
+ the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but checks the date of the version on the repository and sees if it has changed. In Ivy this is supported using the link:ivyfile/dependency.html[changing attribute] on a dependency or by configuring the link:configuration/resolvers.html[changing pattern] to use for all your modules.
+
+* automatically create a new version for each +
+ in this case you use either a build number or a timestamp to publish each new integration version with a new version name. Then you can use one of the numerous ways in Ivy to link:ivyfile/dependency.html[express a version constraint]. Usually selecting the very latest one (using 'latest.integration' as version constraint) is enough.
+
+
+So, which way is the best? As often, it depends on your context, and if one of the two was really bad it wouldn't be supported in Ivy :-)
+
+But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make *all* your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.
+
+Imagine you have a customer who comes on a Monday morning and asks for the latest version of your software, for testing or demonstration purposes. Obviously he needs it for the afternoon :-) Now if you have a continuous integration process and good tracking of your changes and your artifacts, it may occur to you that you are actually able to fulfill his request without needing the use of a DeLorean to give you some more time :-) But it may also occur to you that your latest version is stable enough to be used for the purpose of the customer, but was actually built a few days ago, because the very latest just broke a feature or introduced a new one you don't want to deliver. You can deliver this 'stable' integration build if you want, but rest assured that a few days, or weeks, or even months later, the customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we all know how they are :-)
+
+So, with a build promotion feature of any build in your repository, the solution would be pretty easy: when the customer asks for the version, you not only deliver the integration build, but you also promote it to a milestone status, for example. This promotion indicates that you should keep track of this version for a long period, to be able to come back to it and create a branch if needed.
+
+Unfortunately Ivy does not by its own allow you to have such reproducible builds out of the box, simply because Ivy is a dependency manager, not a build tool. But if you publish only versions with a distinct name and use Ivy features like versions constraint replacement during the publication or recursive delivery of modules, it can really help.
+
+On the other hand, the main drawback of this solution is that it can produce a lot of intermediate versions, and you will have to run some cleaning scripts in your repository unless your company name starts with a G and ends with oogle :-)
+
+
+== Inlining dependencies or not?
+
+With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This pratice is called inlining. But what is it good for, and when should it be avoided?
+
+Putting ivy dependencies in a separate file has the following advantages:
+
+
+* separate revision cycle +
+ if your dependencies may change more often than your build, it's a good idea to separate the two, to isolate the two concepts: describing how to build / describing your project dependencies
+
+* possibility to publish +
+ if you describe dependencies of a module which can itself be reused, you may want to use ant to publish it to a repository. In this case the publication is only possible if you have a separate ivy file
+
+* more flexible +
+ inline dependencies can only be used to express one dependency and only one. An ivy file can be used to express much more complex dependencies
+
+On the other hand, using inline dependencies is very useful when:
+
+
+* you want to use a custom task in your ant build +
+ Without ivy you usually either copy the custom task jar in ant lib, which requires maintenance of your workstation installation, or use a manual copy or download and a taskdef with the appropriate classpath, which is better. But if you have several custom tasks, or if they have themselves dependencies, it can become cumbersome. Using Ivy with an inline dependency is an elegant way to solve this problem.
+
+* you want to easily deploy an application +
+ If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybee packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of *any* version of your application available in your repository!
+
+
+== Hire an expert
+
+Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.
+
+Therefore hiring a build and dependency expert to analyse and improve your build and release system is most of the time a very good choice.
+
+
+== Feedback
+
+These best practices reflect our own experience, but we do not pretend to own the unique truth about dependency management or even Ivy use.
+
+So feel free to comment on this page to add your own experience feedback, suggestions or opinion.
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/compatibility.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/compatibility.adoc b/asciidoc/compatibility.adoc
new file mode 100644
index 0000000..748b899
--- /dev/null
+++ b/asciidoc/compatibility.adoc
@@ -0,0 +1,30 @@
+
+
+== JVM compability
+
+
+Up to Ivy 2.3.x, a minimum of Java 1.4 is required.
+
+For Ivy 2.4.0, a minimum of Java 5 is required.
+
+Since Ivy 2.5.0, a minimum of Java 7 is required.
+
+
+== Apache Ant
+
+
+Ivy doesn't require a specific version of Ant as long as the Ant being used complies with the JVM compatibility requirements noted above.
+
+
+== Other optional dependencies
+
+
+The required versions of the Apache HttpClient, Jsch or any optional dependency are to be checked against Ivy's dependency descriptor. In Ivy's source, check for the ivy.xml file at the root. Or the pom.xml of `org.apache.ivy#ivy` in the Maven Central repository.
+
+
+== Environment / Configuration Requirements
+
+
+Ivy does not at this time support multithreaded use. It thus should not be used with the ant `<parallel>` task.
+
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/concept.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/concept.adoc b/asciidoc/concept.adoc
new file mode 100644
index 0000000..45e0f25
--- /dev/null
+++ b/asciidoc/concept.adoc
@@ -0,0 +1,404 @@
+
+
+== [[dependency-resolver]]Dependency Resolver
+
+A dependency resolver is a pluggable class in ivy which is used to:
+
+
+* find dependencies' ivy files +
+
+* download dependencies' artifacts +
+
+The notion of artifact "downloading" is large: an artifact can be on a web site, or on the local file system of your machine. The download is thus the act of bring a file from a repository to the ivy cache.
+
+Moreover, the fact that it is the responsibility of the resolver to find ivy files and download artifacts helps to implement various resolving strategies.
+
+As you see, a dependency resolver can be thought of as a class responsible for describing a repository.
+
+If you want to see which resolvers are available in ivy, you can go to the link:settings/resolvers.html[resolvers configuration page].
+
+
+== [[configurations]]Module configurations explained
+
+Module configurations are described in the terminology page as _a way to use or construct a module_. Configurations being a central part of Ivy, they need more explanations as a concept.
+
+
+When you define a way to use or construct a module, you are able to define which artifacts are published by this module in this configuration, and you are also able to define which dependencies are needed in this configuration.
+
+Moreover, because dependencies in ivy are expressed on modules and not on artifacts, it is important to be able to define which configurations of the dependency are required in the configuration you define of your module. That's what is called *configuration mapping*.
+
+If you use only simple modules and do not want to worry about configurations, you don't have to worry about them. They're still there under the hood because ivy can't work without configurations. But most of the time if you declare nothing, ivy assumes that the artifacts of your module are published in all configurations, and that all the dependencies' configurations are required in all configurations. And it works in simple cases. But whenever you want to separate things within a module, or get more control over things published and get better dependencies resolution, configurations will meet most of your needs.
+
+For details on how to declare your module configurations, how to declare in which configuration your artifacts are published, and how to declare configuration mapping, please refer to link:ivyfile.html[ivy file documentation]. The link:tutorial/conf.html[configurations tutorial] is also a good place to go to learn more about this concept.
+
+
+== [[variables]]Variables
+
+During configuration, ivy allows you to define what are called ivy variables. Ivy variables can be seen as ant properties, and are used in a very similar way. In particular, you use a properties tag in the configuration file to load a properties file containing ivy variables and their values.
+
+But the main differences between ant properties and ivy variables are that ivy variables can be overridden, whereas ant
+properties can't, and that they are defined in separate environments.
+
+Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant).
+This means that if you define an ant property after the call to configure, it will not be available as an ivy variable.
+On the other hand, ivy variables are NOT exported to ant, thus if you define ivy variables in ivy, do not try to use them as ant properties.
+
+To use ivy variables, you just have to follow the same syntax as for ant properties:
+${__variablename__}
+where __variablename__ is the name of the variable.
+
+Finally, it's also important to be aware of the time of substitution of variables. This substitution is done as soon as possible. This means that when ivy encounters a reference to a variable, it tries to substitute it if such a variable is defined. Consequently, *any later modification of the variable will not alter the value already substituted*.
+
+Moreover, in an ant environment, a bunch of variables are going to be set by default via the ant property file loading mechanism (actually they are first loaded as ant properties and then imported as ivy variables, see link:ant.html[Ant Tasks]), and even in the ant properties themselves there is going to be eager substitution on loading, effectively making it impossible to override some variable purely via the ivysettings.properties file. Some variables will really only be able to be overridden via ant properties because of this.
+
+Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens.
+See the Patterns chapter below for what pattern tokens are.
+
+== [[patterns]]Patterns
+
+
+Ivy patterns are used in many dependency resolvers and ivy tasks, and are a simple way to structure the way ivy works.
+
+First let's give an example. You can for instance configure the file system dependency resolver by giving it
+a pattern to find artifacts. This pattern can be like this:
+myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
+
+This pattern indicates that the repository we use is in a directory called myrepository.
+
+In this directory we have directories having for name the name of the organisation of the module we look for.
+Then we have a directory per module, each having for name the name of the module.
+Then in module directories we find a directory per artifact type (jars, wars, ivys, ...), in which we find artifacts named by the artifact id, followed by a hyphen, then the revision, a dot, and the artifact extension.
+Not too difficult to understand is it? That's it, you have understood the pattern concept!
+
+To give a bit more explanation, a pattern is composed of tokens, which are replaced by actual values when evaluated for a particular artifact or module. Those tokens are different from variables because they are replaced differently for each artifact, whereas variables are usually given the same value.
+
+You can mix variables and tokens in a pattern:
+${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
+
+
+
+The tokens available depends on where the pattern is used (will it be evaluated with artifacts or modules, for instance).
+But here are all the tokens currently available:
+
+
+* [organisation] +
+ the organisation name
+
+* [orgPath] *__(since 2.3)__* +
+ the organisation name where '.' has been replaced by '/'. This can be used to configure maven2-like repositories.
+
+* [module] +
+ the module name
+
+* [branch] +
+ the branch name
+
+* [revision] +
+ the revision name
+
+* [artifact] +
+ the artifact name (or id)
+
+* [type] +
+ the artifact type
+
+* [ext] +
+ the artifact file extension
+
+* [conf] +
+ the configuration name
+
+* [originalname] *__(since 1.4)__* +
+ the original artifact name (including the extension)
+
+
+The difference between type and extension is explained in the ivy file documentation.
+
+*__since 1.2__* [organization] can be used instead of [organisation].
+
+*__since 1.3__* Optional parts can be used in patterns.
+This provides the possibility to avoid some input when a token is not defined, instead of having only the token as blank. Parenthesis are used to delimit the optional part, and only one token can be found inside the parenthesis.
+So if you surround a token with '(' and ')', any other text which is between the parenthesis will be ignored if the token has no value.
+
+For instance, suppose the pattern: "abc(def[type]ghi)"
+type = "jar" -> the substituted pattern: abcdefjarghi
+type = null or "" -> the substitued pattern: abc
+
+A more real life example:
+The pattern
+[source]
+----
+[artifact](-[revision]).[ext]
+----
+
+lets you accept both myartifact-1.0.jar when a revision is set, and myartifact.jar (instead of myartifact-.jar) when no revision is set.
+This is particularly useful when you need to keep control of artifact names.
+
+*__since 1.4__* Extra attributes can be used as any other token in a pattern.
+
+
+== [[latest]]Latest Strategy
+
+Ivy often needs to know which revision between two is considered the "latest". To know that, it uses the concept of latest strategy. Indeed, there are several ways to consider a revision to be the latest. You can choose an existing one or plug in your own.
+
+But before knowing which revision is the latest, ivy needs to be able to consider several revisions of a module. Thus ivy has to get a list of files in a directory, and it uses the dependency resolver for that. So check if the dependency resolver you use is compatible with latest revisions before wondering why ivy does not manage to get your latest revision.
+
+Finally, in order to get several revisions of a module, most of the time you need to use the [revision] token in your pattern so that ivy gets all the files which match the pattern, whatever the revision is. It's only then that the latest strategy is used to determine which of the revisions is the latest one.
+
+Ivy has three built-in latest strategies:
+
+
+* latest-time +
+ This compares the revisions date to know which is the latest. While this is often a good strategy in terms of pertinence, it has the drawback of being costly to compute for distant repositories. If you use ivyrep, for example, ivy has to ask the http server what is the date of each ivy file before knowing which is the latest.
+
+* latest-revision +
+ This compares the revisions as strings, using an algorithm close to the one used in the php version_compare function.
+This algorithm takes into account special meanings of some text. For instance, with this strategy, 1.0-dev1 is considered before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
+
+* latest-lexico +
+ This compares the revisions as strings, using lexicographic order (the one used by the Java string comparison).
+
+
+See also how to configure new latest strategies link:settings/latest-strategies.html[here].
+
+
+== [[conflict]]Conflict Manager
+
+A conflict manager is able to select, among a list of module revisions in conflict, a list of revisions to keep.
+Yes, it can select a list of revisions, even if most conflict managers select only one revision.
+But in some cases you will need to keep several revisions, and load in separate class loaders, for example.
+
+A list of revisions is said to be in conflict if they correspond to the same module, i.e. the same organisation/module name couple.
+
+The list of available conflict managers is available on the link:settings/conflict-managers.html[conflict manager configuration page].
+
+For more details on how to setup your conflict managers by module, see the link:ivyfile/conflicts.html[conflicts] section in the ivy file reference.
+
+
+== [[matcher]]Pattern matcher
+
+*__since 1.3__*
+In several places Ivy uses a pattern to match a set of objects. For instance, you can exclude several modules at once when declaring a dependency by using a pattern matching all the modules to exclude.
+
+Ivy uses a pluggable pattern matcher to match those object names. 3 are defined by default:
+
+
+* exact +
+This matcher matches only using strings
+
+* regexp +
+This matcher lets you use a regular expression as supported by the Pattern class of java 1.4 or greater
+
+* glob +
+This matcher lets you use a Unix-like glob matcher, i.e. where the only meta characters are * which matches any sequence of characters and ? which matches exactly one character. Note that this matcher is available only with jakarta oro 2.0.8 in your classpath.
+
+Note also that with any matcher, the character '*' has the special meaning of matching anything. This is particularly useful with default values which do not depend on the matcher.
+
+
+== [[extra]]Extra attributes
+
+*__since 1.4__*
+Several tags in ivy xml files are extensible with what is called extra attributes.
+The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns.
+
+*__since 2.0__*
+It's possible and recommended to use xml namespaces for your extra attributes. Using an Ivy extra namespace is the easiest way to add your own extra attributes.
+
+Example:
+Here is an ivy file with the attribute 'color' set to blue:
+
+[source]
+----
+
+<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
+ <info organisation="apache"
+ module="foo"
+ e:color="blue"
+ status="integration"
+ revision="1.59"
+ />
+</ivy-module>
+
+----
+
+Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes
+will indeed be used as identifiers for the module like the org the name and the revision:
+
+[source]
+----
+
+<dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
+
+----
+
+And you can define your repository pattern as:
+
+[source]
+----
+
+${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
+
+----
+
+Note that in patterns you must use the unqualified attribute name (no namespace prefix).
+
+If you don't want to use xml namespaces, it's possible but you will need to disable ivy file validation, since your files won't fulffill anymore the official ivy xsd. See the link:settings/settings.html[settings documentation] to see how to disable validation.
+
+== [[checksum]]Checksums
+
+*__since 1.4__*
+Ivy allows the use of checksums, also known as digests, to verify the correctness of a downloaded file.
+
+The configuration of using the algorithm can be done globally or by dependency resolver.
+Globally, use the ivy.checksums variable to list the check to be done.
+On each resolver you can use the checksums attribute to override the global setting.
+
+The setting is a comma separated list of checksum algorithms to use.
+During checking (at download time), the first checksum found is checked, and that's all. This means that if you have a "SHA-256, sha1, md5" setting, then if ivy finds a SHA-256 file, it will compare the downloaded file SHA-256 against this SHA-256, and if the comparison is ok, it will assume the file is ok. If no SHA-256 file is found, it will look for an sha1 file. If that isn't found, then it checks for md5 and so on. If none is found no checking is done.
+During publish, all listed checksum algorithms are computed and uploaded.
+
+By default checksum algorithms are "sha1, md5".
+
+If you want to change this default, you can set the variable ivy.checksums. Hence, to disable checksum validation you just have to set ivy.checksums to "".
+
+
+=== Supported algorithms
+
+*__since 1.4__*
+
+
+* md5 +
+
+* sha1 +
+
+*__since 2.5__*
+Starting 2.5 version, in addition to md5 and sha1, Ivy supports SHA-256, SHA-512 and SHA-384 algorithms, if the Java runtime in which Ivy is running, supports those. For example, Java 6 runtime supports SHA-256 and SHA-512 as standard algorithms. If Ivy 2.5 and later versions are run under Java 6 or higher runtimes, these algorithms are supported by Ivy too.
+
+
+== [[event]]Events and Triggers
+
+*__since 1.4__*
+When Ivy performs the dependency resolution and some other tasks, it fires events before and after the most important steps. You can listen to these events using Ivy API, or you can even register a trigger to perform a particular action when a particular event occur.
+
+This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accuratly, and so on.
+
+For more details about events and triggers, see the link:settings/triggers.html[triggers] documentation page in the configuration section of this documentation.
+
+
+== [[circular]]Circular Dependencies
+
+*__since 1.4__*
+Circular dependencies can be either direct or indirect. For instance, if A depends on A, it's a circular dependency, and if A depends on B which itself depends on A, this is also a circular dependency.
+
+Prior to Ivy 1.4 circular dependencies where causing a failure in Ivy. As of Ivy 1.4, the behaviour of Ivy when it finds a circular dependency is configurable through a circular dependency strategy.
+
+3 built-in strategies are available:
+
+
+* ignore +
+ circular dependencies are only signaled in verbose messages
+
+* warn +
+ same as ignore, except that they are signaled as a warning (default)
+
+* error +
+ halt the dependency resolution when a circular dependency is found
+
+
+See the link:settings/settings.html[configuration page] to see how to configure the circular dependency strategy you want to use.
+
+
+== Cache and Change Management
+
+Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.
+
+
+=== [[cache]]Cache types
+
+An Ivy cache is composed of two different parts:
+
+
+* the repository cache +
+The repository cache is where Ivy stores data downloaded from module repositories, along with some meta information concerning these artifacts, like their original location.
+This part of the cache can be shared if you use a well suited link:settings/lock-strategies.html[lock strategy].
+
+* the resolution cache +
+This part of the cache is used to store resolution data, which is used by Ivy to reuse the results of a resolve process.
+This part of the cache is overwritten each time a new resolve is performed, and should never be used by multiple processes at the same time.
+
+
+While there is always only one resolution cache, you can link:settings/caches.html[define multiple repository caches], each link:settings/resolvers.html[resolver] being able to use a separate cache.
+
+
+=== [[change]]Change management
+
+To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several link:bestpractices.html[good reasons] to follow this principle.
+
+However, depending on your current build system and your dependency management strategy, you may prefer to update your modules sometimes. There are two kinds of changes to consider:
+
+==== Changes in module metadata
+
+Since pretty often module metadata are not considered by module providers with as much attention as their API or behavior (if they even provide module metadata), it happens more than we would like that we have to update module metadata: a dependency has been forgotten, or another one is missing, ...
+
+In this case, setting checkModified="true" on your dependency resolver will be the solution. This flag tells Ivy to check if module metadata has been modified compared to the cache. Ivy first checks the metadata last modified timestamp on the repository to download it only if necessary, and then updates it when needed.
+
+==== Changes in artifacts
+
+Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps save disk space to keep only one version for the high number of intermediary builds you can make whilst developing.
+
+Ivy supports this kind of approach with the notion of "changing revision". A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the link:ivyfile/dependency.html[dependency] tag, or use the changingPattern and changingMatcher attributes on your link:settings/resolvers.html[resolvers] to indicate which revision or group of revisions should be considered as changing.
+
+Once Ivy knows that a revision is changing, it will follow this principle to avoid checking your repository too often: if the module metadata has not changed, it will considered the whole module (including artifacts) as not changed. Even if the module descriptor file has changed, it will check the publication data of the module to see if this is a new publication of the same revision or not. Then if the publication date has changed, it will check the artifacts' last modified timestamps, and download them accordingly.
+
+So if you want to use changing revisions, use the link:use/publish.html[publish] task to publish your modules, it will take care of updating the publication date, and everything will work fine. And remember to set checkModified=true" on your resolver too!
+
+== [[paths]]Paths handling
+
+As a dependency manager, Ivy has a lot of file related operations, which most of the time use paths or path patterns to locate the file on the filesystem.
+
+These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like
+[source]
+----
+${ivy.basedir}/ivy.xml
+----
+
+, you have an absolute path. In link:settings.html[settings files], you also have a variable called ivy.settings.dir which points to the directory in which your settings file is located, which makes defining paths relative to this directory very easy.
+
+If you really want to use relative paths, the base directory used to actually locate the file depends on where the relative path is defined:
+
+
+* In an Ivy file, paths are relative to the Ivy file itself (the only possible path in an Ivy file is for configurations declaration inclusion) +
+
+* In settings files, paths for file inclusion (namely properties file loading and settings inclusion) are relative to the directory in which the settings file is located. All other paths must be absolute unless explicitly noted. +
+
+* In Ivy Ant tasks and Ivy parameters or options, paths are relative to Ivy base directory, which when called from Ant is the same as your Ant basedir. +
+
+
+
+== [[packaging]]Packaging
+
+
+Most of the artifacts found in a repository are jars. They can be downoaded and used as is. But some other kind of artifacts required some __unpacking__ after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with *packaging*.
+
+A __packaged__ artifact needs to be declared as such in the module descriptor via the attribute link:ivyfile/artifact.html[packaging]. The value of that attribute defined which kind of unpacking algorithm must be used. Here are the list of currently supported algorithms:
+
+
+* `zip`, `jar` or `war`: the artifact will be uncompressed as a folder +
+
+* `pack200`: the artifact will be unpacked to a file via the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm +
+
+* `bundle`: the OSGi artifact will be uncompressed as a folder, and every embedded jar file entry which is packed via the the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm will be unpacked +
+
+
+So, if in an `ivy.xml`, there would be declared a such artifact:
+
+[source]
+----
+
+ <artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200" />
+
+----
+
+A file `mymodule-1.2.3.jar.pack.gz` would be download into the cache, and also uncompressed in the cache to `mymodule-1.2.3.jar`. Then any post resolve task which supports it, like the link:use/cachepath.html[cachepath], will use the uncompressed file instead of the orginal compressed file.
+
+It is possible to chain packing algorithm. The attribute link:ivyfile/artifact.html[packaging] of a artifact expects a comma separated list of packing types, in packing order. For instance, an artifact '`mymodule-1.2.3.jar.pack.gz`' can have the packaging '`jar,pack200`', so it would be uncompressed as a folder '`mymodule-1.2.3`'.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration.adoc b/asciidoc/configuration.adoc
new file mode 100644
index 0000000..0d4e90d
--- /dev/null
+++ b/asciidoc/configuration.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:settings.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/caches.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/caches.adoc b/asciidoc/configuration/caches.adoc
new file mode 100644
index 0000000..9bc4dec
--- /dev/null
+++ b/asciidoc/configuration/caches.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/caches.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/caches/cache.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/caches/cache.adoc b/asciidoc/configuration/caches/cache.adoc
new file mode 100644
index 0000000..e7bbbc6
--- /dev/null
+++ b/asciidoc/configuration/caches/cache.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/caches/cache.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/caches/ttl.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/caches/ttl.adoc b/asciidoc/configuration/caches/ttl.adoc
new file mode 100644
index 0000000..654ddf3
--- /dev/null
+++ b/asciidoc/configuration/caches/ttl.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/caches/ttl.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/classpath.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/classpath.adoc b/asciidoc/configuration/classpath.adoc
new file mode 100644
index 0000000..3f77f9a
--- /dev/null
+++ b/asciidoc/configuration/classpath.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/classpath.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/conf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/conf.adoc b/asciidoc/configuration/conf.adoc
new file mode 100644
index 0000000..751790f
--- /dev/null
+++ b/asciidoc/configuration/conf.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/settings.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/conflict-managers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/conflict-managers.adoc b/asciidoc/configuration/conflict-managers.adoc
new file mode 100644
index 0000000..5b3427c
--- /dev/null
+++ b/asciidoc/configuration/conflict-managers.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/conflict-managers.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/include.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/include.adoc b/asciidoc/configuration/include.adoc
new file mode 100644
index 0000000..6edb04f
--- /dev/null
+++ b/asciidoc/configuration/include.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/include.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/latest-strategies.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/latest-strategies.adoc b/asciidoc/configuration/latest-strategies.adoc
new file mode 100644
index 0000000..7fd1d56
--- /dev/null
+++ b/asciidoc/configuration/latest-strategies.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/latest-strategies.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/lock-strategies.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/lock-strategies.adoc b/asciidoc/configuration/lock-strategies.adoc
new file mode 100644
index 0000000..7187311
--- /dev/null
+++ b/asciidoc/configuration/lock-strategies.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/lockstrategies.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/macrodef.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/macrodef.adoc b/asciidoc/configuration/macrodef.adoc
new file mode 100644
index 0000000..d22978c
--- /dev/null
+++ b/asciidoc/configuration/macrodef.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/macrodef.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/macrodef/attribute.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/macrodef/attribute.adoc b/asciidoc/configuration/macrodef/attribute.adoc
new file mode 100644
index 0000000..9645252
--- /dev/null
+++ b/asciidoc/configuration/macrodef/attribute.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/macrodef/attribute.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/module.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/module.adoc b/asciidoc/configuration/module.adoc
new file mode 100644
index 0000000..c7b4ebb
--- /dev/null
+++ b/asciidoc/configuration/module.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/module.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/modules.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/modules.adoc b/asciidoc/configuration/modules.adoc
new file mode 100644
index 0000000..dfd6a8a
--- /dev/null
+++ b/asciidoc/configuration/modules.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/modules.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespace.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace.adoc b/asciidoc/configuration/namespace.adoc
new file mode 100644
index 0000000..6ea8678
--- /dev/null
+++ b/asciidoc/configuration/namespace.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/namespace.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespace/dest.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace/dest.adoc b/asciidoc/configuration/namespace/dest.adoc
new file mode 100644
index 0000000..859016f
--- /dev/null
+++ b/asciidoc/configuration/namespace/dest.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/namespace/dest.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespace/fromtosystem.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace/fromtosystem.adoc b/asciidoc/configuration/namespace/fromtosystem.adoc
new file mode 100644
index 0000000..8ec0b9b
--- /dev/null
+++ b/asciidoc/configuration/namespace/fromtosystem.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/namespace/fromtosystem.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespace/rule.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace/rule.adoc b/asciidoc/configuration/namespace/rule.adoc
new file mode 100644
index 0000000..1133b2e
--- /dev/null
+++ b/asciidoc/configuration/namespace/rule.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/namespace/rule.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespace/src.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace/src.adoc b/asciidoc/configuration/namespace/src.adoc
new file mode 100644
index 0000000..4fdf870
--- /dev/null
+++ b/asciidoc/configuration/namespace/src.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../../settings/namespace/src.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/namespaces.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespaces.adoc b/asciidoc/configuration/namespaces.adoc
new file mode 100644
index 0000000..e39593d
--- /dev/null
+++ b/asciidoc/configuration/namespaces.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/namespaces.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/outputters.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/outputters.adoc b/asciidoc/configuration/outputters.adoc
new file mode 100644
index 0000000..b4dfe76
--- /dev/null
+++ b/asciidoc/configuration/outputters.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/outputters.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/parsers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/parsers.adoc b/asciidoc/configuration/parsers.adoc
new file mode 100644
index 0000000..f0a85cf
--- /dev/null
+++ b/asciidoc/configuration/parsers.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/parsers.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/properties.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/properties.adoc b/asciidoc/configuration/properties.adoc
new file mode 100644
index 0000000..295a9ac
--- /dev/null
+++ b/asciidoc/configuration/properties.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/properties.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/property.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/property.adoc b/asciidoc/configuration/property.adoc
new file mode 100644
index 0000000..c886cb6
--- /dev/null
+++ b/asciidoc/configuration/property.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/property.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/resolvers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/resolvers.adoc b/asciidoc/configuration/resolvers.adoc
new file mode 100644
index 0000000..7182214
--- /dev/null
+++ b/asciidoc/configuration/resolvers.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/resolvers.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/status.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/status.adoc b/asciidoc/configuration/status.adoc
new file mode 100644
index 0000000..3b56a00
--- /dev/null
+++ b/asciidoc/configuration/status.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/status.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/statuses.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/statuses.adoc b/asciidoc/configuration/statuses.adoc
new file mode 100644
index 0000000..1e90f95
--- /dev/null
+++ b/asciidoc/configuration/statuses.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/statuses.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/triggers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/triggers.adoc b/asciidoc/configuration/triggers.adoc
new file mode 100644
index 0000000..ce355a0
--- /dev/null
+++ b/asciidoc/configuration/triggers.adoc
@@ -0,0 +1,3 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/triggers.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/typedef.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/typedef.adoc b/asciidoc/configuration/typedef.adoc
new file mode 100644
index 0000000..7a2c7ad
--- /dev/null
+++ b/asciidoc/configuration/typedef.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/typedef.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/configuration/version-matchers.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/version-matchers.adoc b/asciidoc/configuration/version-matchers.adoc
new file mode 100644
index 0000000..1c9bbba
--- /dev/null
+++ b/asciidoc/configuration/version-matchers.adoc
@@ -0,0 +1,4 @@
+
+This page has moved. If your browser doesn't automatically redirect to its new location, click
+link:../settings/version-matchers.html[here].
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/22bdffb9/asciidoc/dev.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev.adoc b/asciidoc/dev.adoc
new file mode 100644
index 0000000..7b307d5
--- /dev/null
+++ b/asciidoc/dev.adoc
@@ -0,0 +1,123 @@
+
+
+== Building from source
+
+To build Ivy from source it's really easy.
+
+=== Requirements
+
+All you need is
+
+
+* an link:http://subversion.tigris.org/[svn] client +
+_to check out Ivy sources from apache svn, not required if you build from sources packaged in a release_
+
+* link:http://ant.apache.org/[Apache Ant] 1.6.0 or greater +
+_We recommend either ant 1.6.5 or 1.7.0_
+
+* link:http://junit.org[junit] 3.8.2 jar in your ant lib +
+_ this is not required if you use ant 1.7_
+
+* a link:http://java.sun.com/[jdk] 1.5 or greater +
+_Build instructions have been successfully tested with sun jdk 1.5.0 and 1.6.0_
+
+
+
+=== Procedure
+
+
+==== Get the source
+
+You can either get the sources from a release, or get them directly from svn. For instance, to get the trunk version:
+
+[source]
+----
+
+svn co https://svn.apache.org/repos/asf/ant/ivy/core/trunk ivy
+
+----
+
+
+==== Build
+
+Go to the directory where you get the Ivy sources (you should see a file named build.xml) and run:
+
+[source]
+----
+
+ant
+
+----
+
+
+==== Check the result
+
+The ant build will compile the core classes of Ivy and use them to resolve the dependencies (used for some optional features). Then it will compile and run tests with coverage metrics.
+
+If everything goes well, you should see the message
+
+[source]
+----
+
+BUILD SUCCESSFUL
+
+----
+
+Then you can check the test results in the build/doc/reports/test directory, the jars are in build/artifacts, and the test coverage report in build/doc/reports/coverage
+
+== Coding conventions
+
+The Ivy code base is supposed to follow the standard java conventions:
+http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
+
+This is a work in progress though (see link:https://issues.apache.org/jira/browse/IVY-511[IVY-511]), but patches helping migration to these conventions are welcome.
+
+
+== Developing with eclipse
+
+Even though you can develop Ivy with your IDE of choice, we support eclipse development by providing ad hoc metadata.
+
+We currently provide two options:
+
+=== Eclipse alone
+
+To develop with a simple eclipse install all you need is eclipse 3.1 or greater, with no particular plugin.
+First call the following ant target in your Ivy workspace:
+
+[source]
+----
+
+ant eclipse-default
+
+----
+
+This will resolve the dependencies of Ivy and produce a .classpath using the resolved jars for the build path.
+Then you can use the "Import->Existing project into workspace" eclipse feature to import the Ivy project in your workspace.
+
+=== Eclipse + IvyDE
+
+You can also leverage the latest IvyDE version to be able to easily resolve the ivy dependencies from Eclipse.
+To do so all you need is call the following ant target in your Ivy workspace:
+
+[source]
+----
+
+ant eclipse-ivyde
+
+----
+
+or if you don't have ant installed you can simply copy the file .classpath.ivyde and rename it to .classpath
+Then you can import the project using "Import->Existing project into workspace" as long as you already have latest IvyDE installed.
+
+To install latest IvyDE version compatible with the latest Ivy used to resolve Ivy dependencies, you will need to use a snapshot build, not endorsed by the ASF, available here:
+http://people.apache.org/~xavier/ivyde/snapshot/
+
+Download the file and unzip its content in your eclipse installation directory.
+
+
+=== recommended plugins
+
+The Ivy project comes with settings for the link:http://eclipse-cs.sourceforge.net/[checkstyle plugin] we recommend to use to avoid introducing new disgression to the checkstyle rules we use.
+If you use this plugin, you will many errors in Ivy. As we said, following strict checkstyle rules is a work in progress and we used to have pretty different code conventions (like using _ as prefix for private attributes), so we still have things to fix. We usually use the filter in the problems view to filter out checkstyle errors from this view, which helps to know what the real compilation problem are.
+
+Besides this plugin we also recommend to use a subversion plugin, link:http://www.eclipse.org/subversive/[subversive] or link:http://subclipse.tigris.org[subclipse] being the two options currently available in the open source landscape.
\ No newline at end of file