We now use asciidoc for 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/0c769150
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/0c769150
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/0c769150

Branch: refs/heads/master
Commit: 0c769150cc2be07dcafc74123cd51d23a7b58a2c
Parents: 1dc8749
Author: Jaikiran Pai <jaiki...@apache.org>
Authored: Wed Mar 7 15:52:25 2018 +0530
Committer: Jaikiran Pai <jaiki...@apache.org>
Committed: Wed Mar 7 15:52:25 2018 +0530

----------------------------------------------------------------------
 .gitmodules                                     |    3 -
 doc/ant.html                                    |  165 --
 doc/apache-proposal.txt                         |  121 --
 doc/bestpractices.html                          |  107 --
 doc/compatibility.html                          |   51 -
 doc/concept.html                                |  313 ---
 doc/config.js                                   |    8 -
 doc/configuration.html                          |   34 -
 doc/configuration/caches.html                   |   34 -
 doc/configuration/caches/cache.html             |   34 -
 doc/configuration/caches/ttl.html               |   34 -
 doc/configuration/classpath.html                |   34 -
 doc/configuration/conf.html                     |   34 -
 doc/configuration/conflict-managers.html        |   34 -
 doc/configuration/include.html                  |   34 -
 doc/configuration/latest-strategies.html        |   34 -
 doc/configuration/lock-strategies.html          |   34 -
 doc/configuration/macrodef.html                 |   34 -
 doc/configuration/macrodef/attribute.html       |   34 -
 doc/configuration/module.html                   |   34 -
 doc/configuration/modules.html                  |   34 -
 doc/configuration/namespace.html                |   34 -
 doc/configuration/namespace/dest.html           |   34 -
 doc/configuration/namespace/fromtosystem.html   |   34 -
 doc/configuration/namespace/rule.html           |   34 -
 doc/configuration/namespace/src.html            |   34 -
 doc/configuration/namespaces.html               |   34 -
 doc/configuration/outputters.html               |   34 -
 doc/configuration/parsers.html                  |   34 -
 doc/configuration/properties.html               |   34 -
 doc/configuration/property.html                 |   34 -
 doc/configuration/resolvers.html                |   34 -
 doc/configuration/status.html                   |   34 -
 doc/configuration/statuses.html                 |   34 -
 doc/configuration/triggers.html                 |   34 -
 doc/configuration/typedef.html                  |   34 -
 doc/configuration/version-matchers.html         |   34 -
 doc/conflict-solving-algo.html                  |  115 --
 doc/dev.html                                    |  102 -
 doc/dev/makerelease.html                        |  225 ---
 doc/extend.html                                 |   55 -
 doc/ideas.txt                                   |   70 -
 doc/images/ant-project-logo.gif                 |  Bin 7577 -> 0 bytes
 doc/images/ant-project-logo.svg                 |  951 ---------
 doc/images/apache-incubator-logo.png            |  Bin 6205 -> 0 bytes
 doc/images/apache-incubator.svg                 |   44 -
 doc/images/bullet.gif                           |  Bin 193 -> 0 bytes
 doc/images/closed.gif                           |  Bin 141 -> 0 bytes
 doc/images/discovery.gif                        |  Bin 362 -> 0 bytes
 doc/images/downloaded.gif                       |  Bin 104 -> 0 bytes
 doc/images/error.gif                            |  Bin 605 -> 0 bytes
 doc/images/evicted.gif                          |  Bin 215 -> 0 bytes
 doc/images/grippie.png                          |  Bin 162 -> 0 bytes
 doc/images/hibgraph-small.png                   |  Bin 9042 -> 0 bytes
 doc/images/hibgraph.png                         |  Bin 51535 -> 0 bytes
 doc/images/hibgraph.svg                         |  173 --
 doc/images/ivy-book.png                         |  Bin 14182 -> 0 bytes
 doc/images/ivy-demo.png                         |  Bin 24544 -> 0 bytes
 doc/images/ivy-dl-1.4.1.png                     |  Bin 10892 -> 0 bytes
 doc/images/ivy-dl-2.0.0-alpha-1.png             |  Bin 12149 -> 0 bytes
 doc/images/ivy-dl.xcf                           |  Bin 29498 -> 0 bytes
 doc/images/ivy-forum.png                        |  Bin 10441 -> 0 bytes
 doc/images/ivy-lierre.png                       |  Bin 15263 -> 0 bytes
 doc/images/ivy-publish-fc.odg                   |  Bin 11126 -> 0 bytes
 doc/images/ivy-publish-fc.png                   |  Bin 20111 -> 0 bytes
 doc/images/ivy-publish-fc.svg                   |  337 ----
 doc/images/ivy-terminology.odg                  |  Bin 22331 -> 0 bytes
 doc/images/ivy-terminology.png                  |  Bin 70573 -> 0 bytes
 doc/images/ivy-terminology.svg                  |  419 ----
 doc/images/ivyfile-small.png                    |  Bin 16328 -> 0 bytes
 doc/images/logo.png                             |  Bin 8772 -> 0 bytes
 doc/images/main-tasks.odg                       |  Bin 12386 -> 0 bytes
 doc/images/main-tasks.png                       |  Bin 32995 -> 0 bytes
 doc/images/main-tasks.svg                       |   82 -
 doc/images/open.gif                             |  Bin 151 -> 0 bytes
 doc/images/report-small.png                     |  Bin 16751 -> 0 bytes
 doc/images/searched.gif                         |  Bin 229 -> 0 bytes
 doc/images/warning.png                          |  Bin 762 -> 0 bytes
 doc/images/xooki-edit-small.png                 |  Bin 30143 -> 0 bytes
 doc/images/xooki-edit.png                       |  Bin 52706 -> 0 bytes
 doc/images/xooki-toolbar.png                    |  Bin 6539 -> 0 bytes
 doc/images/yed-step1.jpg                        |  Bin 3077 -> 0 bytes
 doc/images/yed-step2.jpg                        |  Bin 15150 -> 0 bytes
 doc/images/yed-step3-2.jpg                      |  Bin 3816 -> 0 bytes
 doc/images/yed-step3.jpg                        |  Bin 21662 -> 0 bytes
 doc/images/yed-step4.jpg                        |  Bin 10558 -> 0 bytes
 doc/images/yed-step5.jpg                        |  Bin 31309 -> 0 bytes
 doc/images/yed-step6.jpg                        |  Bin 21240 -> 0 bytes
 doc/images/yed-step7.jpg                        |  Bin 51973 -> 0 bytes
 doc/index.html                                  |   81 -
 doc/install.html                                |   89 -
 doc/ivyfile.html                                |  137 --
 doc/ivyfile/artifact-conf.html                  |   46 -
 doc/ivyfile/artifact-exclude-conf.html          |   46 -
 doc/ivyfile/artifact-exclude.html               |   83 -
 doc/ivyfile/artifact.html                       |  100 -
 doc/ivyfile/conf.html                           |   86 -
 doc/ivyfile/configurations.html                 |  114 --
 doc/ivyfile/conflict.html                       |   66 -
 doc/ivyfile/conflicts.html                      |   69 -
 doc/ivyfile/dependencies.html                   |   76 -
 doc/ivyfile/dependency-artifact-conf.html       |   46 -
 doc/ivyfile/dependency-artifact.html            |  109 --
 doc/ivyfile/dependency-conf.html                |   61 -
 doc/ivyfile/dependency-include-conf.html        |   46 -
 doc/ivyfile/dependency-include.html             |   78 -
 doc/ivyfile/dependency.html                     |  225 ---
 doc/ivyfile/description.html                    |   49 -
 doc/ivyfile/exclude.html                        |   60 -
 doc/ivyfile/extends.html                        |   67 -
 doc/ivyfile/include.html                        |   75 -
 doc/ivyfile/info.html                           |   77 -
 doc/ivyfile/ivyauthor.html                      |   48 -
 doc/ivyfile/license.html                        |   47 -
 doc/ivyfile/manager.html                        |   61 -
 doc/ivyfile/mapped.html                         |   47 -
 doc/ivyfile/override.html                       |   61 -
 doc/ivyfile/publications.html                   |   60 -
 doc/ivyfile/repository.html                     |   54 -
 doc/js/jquery.pack.js                           |    1 -
 doc/js/jquery.treeview.js                       |  239 ---
 doc/moreexamples.html                           |   52 -
 doc/osgi.html                                   |   64 -
 doc/osgi/eclipse-plugin.html                    |   88 -
 doc/osgi/osgi-mapping.html                      |  232 ---
 doc/osgi/sigil.html                             |   58 -
 doc/osgi/standard-osgi.html                     |   60 -
 doc/osgi/target-platform.html                   |   67 -
 doc/principle.html                              |   79 -
 doc/printTemplate.html                          |   57 -
 doc/reference.html                              |   59 -
 doc/release-notes.html                          |  250 ---
 doc/resolver/bintray.html                       |   69 -
 doc/resolver/chain.html                         |   93 -
 doc/resolver/dual.html                          |   52 -
 doc/resolver/filesystem.html                    |   92 -
 doc/resolver/ibiblio.html                       |   81 -
 doc/resolver/ivyrep.html                        |   66 -
 doc/resolver/jar.html                           |   89 -
 doc/resolver/mirrored.html                      |   91 -
 doc/resolver/obr.html                           |   76 -
 doc/resolver/osgiagg.html                       |   58 -
 doc/resolver/packager.html                      |  401 ----
 doc/resolver/sftp.html                          |  133 --
 doc/resolver/ssh.html                           |  106 -
 doc/resolver/updatesite.html                    |   72 -
 doc/resolver/url.html                           |   75 -
 doc/resolver/vfs.html                           |   64 -
 doc/running.html                                |   35 -
 doc/samples/apache-hello-ivy-default.html       |  371 ----
 doc/samples/build-install.xml                   |   72 -
 doc/samples/build.xml                           |  151 --
 doc/samples/commons-lang1.0-dep-report-part.jpg |  Bin 12087 -> 0 bytes
 doc/samples/eclipse-plugin/build.xml            |   77 -
 doc/samples/eclipse-plugin/ivy.xml              |   39 -
 .../eclipse-plugin/ivysettings.properties       |   21 -
 doc/samples/eclipse-plugin/ivysettings.xml      |   36 -
 doc/samples/hibernate3.0-dep-report-part.jpg    |  Bin 35112 -> 0 bytes
 doc/samples/ivy-doc.xsl                         |  281 ---
 doc/samples/ivy-report.css                      |  279 ---
 doc/samples/ivy-sample-xslt.xml                 |  101 -
 doc/samples/ivy-sample.xml                      |  100 -
 doc/samples/ivy-style.css                       |  160 --
 doc/samples/ivysettings-default.xml             |   24 -
 .../jayasoft-ivyrep-example-default.html        |  371 ----
 doc/samples/jayasoft-ivyrep-example-default.jpg |  Bin 12564 -> 0 bytes
 .../projects-dependencies-graph-small.jpg       |  Bin 18280 -> 0 bytes
 doc/samples/projects-dependencies-graph.jpg     |  Bin 53526 -> 0 bytes
 doc/samples/standard-osgi/build.xml             |   83 -
 doc/samples/standard-osgi/ivy.xml               |   24 -
 doc/samples/standard-osgi/ivysettings.xml       |   34 -
 .../org.apache.ivy.sample.standard-osgi.bnd     |   18 -
 doc/samples/target-platform/build.xml           |   56 -
 doc/samples/target-platform/ivy.xml             |   24 -
 doc/samples/target-platform/ivysettings.xml     |   33 -
 doc/settings.html                               |  158 --
 doc/settings/caches.html                        |   92 -
 doc/settings/caches/cache.html                  |   92 -
 doc/settings/caches/ttl.html                    |   71 -
 doc/settings/classpath.html                     |   71 -
 doc/settings/conflict-managers.html             |   66 -
 doc/settings/credentials.html                   |   50 -
 doc/settings/include.html                       |   80 -
 doc/settings/latest-strategies.html             |   88 -
 doc/settings/lock-strategies.html               |   57 -
 doc/settings/macrodef.html                      |  151 --
 doc/settings/macrodef/attribute.html            |   47 -
 doc/settings/module.html                        |  110 --
 doc/settings/modules.html                       |   51 -
 doc/settings/namespace.html                     |  127 --
 doc/settings/namespace/dest.html                |   62 -
 doc/settings/namespace/fromtosystem.html        |   46 -
 doc/settings/namespace/rule.html                |   48 -
 doc/settings/namespace/src.html                 |   48 -
 doc/settings/namespaces.html                    |   58 -
 doc/settings/outputters.html                    |   65 -
 doc/settings/parsers.html                       |   53 -
 doc/settings/properties.html                    |   51 -
 doc/settings/property.html                      |   70 -
 doc/settings/resolvers.html                     |  211 --
 doc/settings/settings.html                      |   81 -
 doc/settings/signers.html                       |   96 -
 doc/settings/status.html                        |   48 -
 doc/settings/statuses.html                      |   72 -
 doc/settings/triggers.html                      |  357 ----
 doc/settings/typedef.html                       |   47 -
 doc/settings/version-matchers.html              |  140 --
 doc/standalone.html                             |  146 --
 doc/style/ant.css                               |   50 -
 doc/style/color.css                             |  159 --
 doc/style/ivy-ref.css                           |   84 -
 doc/style/nav.css                               |   28 -
 doc/style/print-style.css                       |  299 ---
 doc/style/shell.css                             |   38 -
 doc/style/style.css                             |  372 ----
 doc/style/tree.css                              |   53 -
 doc/template.html                               |  116 --
 doc/terminology.html                            |  134 --
 doc/textual.html                                |  139 --
 doc/toc.json                                    |  957 ---------
 doc/tutorial.html                               |   63 -
 doc/tutorial/build-repository.html              |   63 -
 doc/tutorial/build-repository/advanced.html     |  118 --
 doc/tutorial/build-repository/basic.html        |  108 --
 doc/tutorial/conf.html                          |  173 --
 doc/tutorial/defaultconf.html                   |  216 ---
 doc/tutorial/dependence.html                    |  192 --
 doc/tutorial/dual.html                          |  128 --
 doc/tutorial/multiple.html                      |  134 --
 doc/tutorial/multiproject.html                  |  216 ---
 doc/tutorial/start.html                         |  104 -
 doc/use.html                                    |   24 -
 doc/use/artifactproperty.html                   |   79 -
 doc/use/artifactreport.html                     |   99 -
 doc/use/buildlist.html                          |  127 --
 doc/use/buildnumber.html                        |  126 --
 doc/use/buildobr.html                           |   91 -
 doc/use/cachefileset.html                       |   59 -
 doc/use/cachepath.html                          |   74 -
 doc/use/checkdepsupdate.html                    |   82 -
 doc/use/cleancache.html                         |   60 -
 doc/use/configure.html                          |   78 -
 doc/use/convertmanifest.html                    |   49 -
 doc/use/convertpom.html                         |   49 -
 doc/use/deliver.html                            |  123 --
 doc/use/dependencytree.html                     |   72 -
 doc/use/findrevision.html                       |   70 -
 doc/use/fixdeps.html                            |   89 -
 doc/use/info.html                               |  171 --
 doc/use/install.html                            |   82 -
 doc/use/listmodules.html                        |   78 -
 doc/use/makepom.html                            |  131 --
 doc/use/postresolvetask.html                    |  118 --
 doc/use/publish.html                            |  115 --
 doc/use/report.html                             |  100 -
 doc/use/repreport.html                          |  117 --
 doc/use/resolve.html                            |  260 ---
 doc/use/resources.html                          |   86 -
 doc/use/retrieve.html                           |  194 --
 doc/use/settings.html                           |   99 -
 doc/use/var.html                                |   57 -
 doc/xooki                                       |    1 -
 doc/xooki2asciidoc/antlib.xml                   |   87 -
 doc/xooki2asciidoc/xooki2asciidoc.js            | 1812 ------------------
 doc/yed.html                                    |   67 -
 265 files changed, 23819 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/.gitmodules
----------------------------------------------------------------------
diff --git a/.gitmodules b/.gitmodules
index d8b91df..e69de29 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +0,0 @@
-[submodule "doc/xooki"]
-       path = doc/xooki
-       url = git://git.apache.org/ant-xooki.git

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/ant.html
----------------------------------------------------------------------
diff --git a/doc/ant.html b/doc/ant.html
deleted file mode 100644
index 2162b78..0000000
--- a/doc/ant.html
+++ /dev/null
@@ -1,165 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 0};</script>   
-       <script type="text/javascript" src="xooki/xooki.js"></script>
-</head>
-<body>
-       <textarea id="xooki-source">
-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 <b>1.6.0</b> or superior, you just have to add ivy 
namespace to your project (<code>xmlns:ivy="antlib:org.apache.ivy.ant"</code> 
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:
-<code>
-<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"/>
-</code>
-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 <b>1.5.1</b> or superior, you have to define the tasks you use 
in your build file. For instance:
-<code>
-  <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"/>
-</code>
-<em>Note: the tasks listed above are non exhaustive. For a complete list of 
tasks with the corresponding classes, see the 
[[gitfile:src/java/org/apache/ivy/ant/antlib.xml antlib.xml]] file in git or 
the version you use.</em>
-
-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.
-<h1>Calling ivy from ant: first steps</h1>
-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:
-<code>
-<ivy:retrieve />
-</code>
-This calls ivy with default values, which might be ok in several projects. In 
fact, it is equivalent to:
-<code type="xml">
-<target name="resolve">
-    <ivy:configure />
-    
-    <ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}" />
-    
-    <ivy:retrieve pattern="${ivy.retrieve.pattern}" 
conf="${ivy.configurations}" />
-</target>
-</code>
-
-Those 3 tasks follow the 3 main steps of the ivy retrieving dependencies 
process:
-<ul>
-<li>First the configure task tells it how it can find dependencies giving it a 
path to an <a href="settings.html">xml settings file</a>.</li> 
-<li>Then the resolve task actually resolves dependencies described by an <a 
href="ivyfile.html">ivy file</a>, and puts those dependencies in the ivy cache 
(a directory configured in the settings file).</li>
-<li>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.</li>
-</ul>
-
-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:
-<code>
-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
-</code>
-<em>For the latest version of these properties, you can check the 
[[gitfile:src/java/org/apache/ivy/core/settings/ivy.properties git 
version]].</em>
-
-<span class="since">since 2.0</span> After calling the first Ivy task, the 
property ivy.version will be available and contains the version of the used Ivy 
library. 
-
-<h1>Ivy tasks attributes : generalities</h1>
-Some tasks attributes values may be given through different places. The three 
possible places are :
-<ol>
-<li>task attribute</li>
-<li>ivy instance</li>
-<li>project property</li>
-</ol>
-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.
-
-<h1>Usual cycle of main tasks</h1>
-<center><img src="images/main-tasks.png" /></center>
-<h1>Example</h1>
-Here is a more complete example of build file using ivy:
-
-<code type="xml">
-<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>
-</code>
-
-All ivy tasks are documented in the following pages.
-
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/apache-proposal.txt
----------------------------------------------------------------------
diff --git a/doc/apache-proposal.txt b/doc/apache-proposal.txt
deleted file mode 100644
index 0a748a3..0000000
--- a/doc/apache-proposal.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-= Ivy Proposal =
-
-The following presents the proposal for creating a new Ivy project within the 
Apache Software Foundation.
-
-== Abstract ==
-Ivy (http://www.jayasoft.org/ivy) is a java based tool for tracking, resolving 
and managing project dependencies.
-
-== Proposal ==
-Ivy is a tool for managing (recording, tracking, resolving and reporting)  
project dependencies. It is characterized by the following:
- 1) flexibility and configurability - Ivy is essentially process agnostic and 
is not tied to any methodology or structure. Instead it provides the necessary 
flexibility and configurability to be adapted to a broad range of dependency 
management and build processes.
- 2) tight integration with Apache Ant - while available as a standalone tool, 
Ivy works particularly well with Apache Ant providing a number of powerful Ant 
tasks ranging from dependency resolution to dependency reporting and 
publication.
-
-== Rationale ==
-
-Software development is increasingly characterized by leveraging externally 
provided components/capabilities and by a rapid release cycle. As a result it 
is not unusual for a project to depend on numerous third-party components which 
themselves may be dependent on a multitude of third-party of different or 
identical third-party components. Managing these dependencies - determining 
what the dependencies are, how they are used, the impact of a change, conflicts 
among dependencies, etc. - is extremely difficult and absolutely necessary. Ivy 
is one of a handful of tools addressing this need. While often compared to 
Maven - which has similar Ant tasks - Ivy differs from Maven in both its focus 
and philosophy. Ivy is solely focused on dependency management and is designed 
from the ground up to adapt to a wide range of requirements and scenarios. 
Examples include multiple aritfacts per module, plugin resolvers, configurable 
repository configurations and conflict managers.
-
-The maintainers of Ivy are interested in joining the Apache Software 
Foundation for several reasons:
-    * Ivy has been hosted since its beginning in 2004 by a private company, 
which make people feel like it's a corporate product, thus slowing the 
contribution by the community. We strongly believe in the open source movement, 
and would like to make Ivy independent from Jayasoft.
-    * We'd like to enjoy the benefits of utilizing Apache's infrastructure and 
legal protection.
-    * It might open the door for cooperation with other projects, such as Ant 
or Maven.
-    * We strongly believe in Apache philosophy, especially Meritocracy.
-
-== Current status ==
-=== Meritocracy ===
-
-Ivy was originally created by Xavier Hanin in September 2004. Since then more 
than 20 users have contributed patches, and one of them has been promoted to 
the status of committer based on his merit through patch contribution.
-
-=== Community ===
-
-Ivy already has a growing user community, with more than 10,000 downloads 
since its 1.0 version and more than 500 users registered on the forum.
-
-=== Core Developers ===
-
-Ivy has only two core developers for the moment, but we hope joining the ASF 
will help increase this number.
-
-Xavier Hanin is the creator of the project, is an independant consultant and 
co founder of Jayasoft. He has an experience of 9 years in Java software 
development, uses open source projects intensively, and started his real 
participation in open source development with Ivy.
-Maarten Coene has joined the committer team in may 2006. He has an experience 
of 9 years in java development, is co-administrator of dom4j, ex-committer for 
scarab, has contributed patches to several open-source projects and is a user 
of a lot of open-source projects.
-
-=== Alignment ===
-
-Ivy has no mandatory dependencies except java 1.4. However, it is strongly 
recommended to be used with Ant. Ivy uses also other Apache projects, 
especially from Jakarta Commons.
-
-== Known risks ==
-
-=== Orphaned products ===
-Due to its small number of committers, there is a risk of being orphaned. The 
main knowledge of the codebase is still mainly owned by Xavier Hanin. Even if 
Xavier has no plan to leave Ivy development, this is a problem we are aware of 
and know that need to be worked on so that the project become less dependent on 
an individual.
-
-=== Inexperience with Open Source ===
-While distributed under an open source license, access to Ivy was initially 
limited with no public access to the issue tracking system or svn repository. 
While things have changed since then - the svn repository is publicly 
accessible, a JIRA instance has been setup since june 2005, many new features 
are first discussed on the forum or JIRA - experience with a true open source 
development model is currently limited.
-However, Maarten has already a good experience with true open development 
process, and bring his experience to the project.
-
-=== Homogenous Developers ===
-With only two core developers, at least they are not homogenous! Xavier and 
Maarten knew each other only due to their common interest in Ivy.
-
-=== Reliance on Salaried Developers ===
-Maarten is not paid to work on Ivy.
-Xavier's case is more complex, as a co founder of Jayasoft, part of his time 
in Jayasoft was dedicated to Ivy and other open source developments. He now 
works mainly as an independent consultant, and thus is not a salaried developer.
-
-=== Relationships with Other Apache Products ===
-Ivy has a strong relationship with Apache Ant, and is often seen as a good 
companion of Ant. Being part of Apache could help for a closer collaboration 
between the two projects.
-
-=== A Excessive Fascination with the Apache Brand ===
-Even if we recognize the strong value of the Apache Brand, the purpose of 
joining Apache is not focused on improving the visibility of the project. The 
main focus of this proposition is to make Ivy a more open project, with a 
closer integration with Apache Ant. Even if Ivy does not join the ASF, Ivy will 
move out of Jayasoft umbrella and try to attract more developers. 
-
-== Documentation ==
-Further reading on Ivy can be found at:
-http://www.jayasoft.org/ivy
-
-== Initial Source ==
-The initial code base can be found at:
-http://svn.jayasoft.org/projects/tools/ivy
-
-== External Dependencies ==
-Ivy has no mandatory dependencies at runtime. 
-
-For compilation, it requires:
-apache ant
-apache commons-httpclient
-apache commons-cli
-apache oro
-apache commons-vfs
-jcraft jsch  (BSD, already used by commons-vfs and by ant)
-
-== Required Resources ==
-
-=== Mailing lists ===
- * ivy-private (with moderated subscriptions) 
- * ivy-dev 
- * ivy-user
- 
-=== Subversion Directory ===
-https://svn.apache.org/repos/asf/incubator/ivy
-
-=== Issue Tracking ===
-JIRA Ivy (IVY) 
-An import from existing JIRA issues at http://jira.jayasoft.org/ would also be 
very much appreciated
-
-== Initial Committers ==
-Xavier Hanin (xavier dot hanin at gmail dot com)
-Maarten Coene (maarten_coene at yahoo dot com)
-
-== Affiliations ==
-As stated in the Reliance on salaried developers section, Xavier is a co 
founder of Jayasoft which used to host the project. However, Jayasoft is 
shifting its focus to local consulting and thus won't be involved anymore in 
open source development. The participation of Xavier in the project is thus 
made as an individual, not as a member of Jayasoft. He also strongly believe in 
the meritocracy principle, and he's ready to see it applied to the project 
whatever the consequence are for his own weight in the project.
-
-== Sponsors ==
-
-=== Champion ===
-Antoine Levy-Lambert
-Sylvain Wallez
-
-=== Nominated Mentors ===
-Antoine Levy-Lambert
-Stephane Baillez
-Steve Loughran
-
-=== Sponsoring Entity ===
-The Ant PMC has voted the following resolution:
-The Ant PMC sponsors Ivy moving to the Apache Incubator.
-If the Ivy community wishes to move Ivy to become an Ant subproject
-after successful incubation, and if the ASF board agrees to it, Ant
-will welcome Ivy as a subproject after the incubation period.

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/bestpractices.html
----------------------------------------------------------------------
diff --git a/doc/bestpractices.html b/doc/bestpractices.html
deleted file mode 100644
index 0a0ca27..0000000
--- a/doc/bestpractices.html
+++ /dev/null
@@ -1,107 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 0};</script>   
-       <script type="text/javascript" src="xooki/xooki.js"></script>
-</head>
-<body>
-       <textarea id="xooki-source">
-Here are some recommendations and best practices we have gathered throughout 
our experience and consultancies with our customers.
-
-<h1>Add module descriptors for all your modules</h1>
-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 <a 
href="concept.html#configurations">configurations</a>). 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 <a href="settings/resolvers.html">resolvers</a>. 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.
-
-<h1>Use your own enterprise repository</h1>
-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:
-<ul>
-<li>control</li> 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.
-<li>reliability</li> 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.
-<li>accuracy</li> 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.
-<li>security</li> 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 <a 
href="http://www.fortifysoftware.com/servlet/downloads/public/fortify_attacking_the_build.pdf";>Forrester
 article</a>.
-</ul>
-Note that using an enterprise repository doesn't mean you have to build it 
entirely by hand. Ivy features an [[ant: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.
-
-<h1>Always use patterns with at least organisation and module</h1>
-Ivy is very flexible and can accomodate a lot of existing repositories, using 
the concept of <a href="concept.html#pattern">patterns</a>. 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 [[ant:install]] or [[ant:repreport]].
-
-<h1>Public ivysettings.xml with public repositories</h1>
-If you create a public repository, provide a URL to the <a 
href="settings.html">ivysettings.xml</a> file. It's pretty easy to do, and if 
someone wants to leverage your repository, he will just have to load it with 
[[ant:settings]] with the URL of your ivysettings.xml file, or <a 
href="configuration/include.html">include</a> it in its own configuration file, 
which makes it really easy to combine several public repositories.
-
-<h1>Dealing with integration versions</h1>
-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:
-<ul>
-<li>use a naming convention like a special suffix</li> 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 <a 
href="ivyfile/dependency.html">changing attribute</a> on a dependency or by 
configuring the <a href="configuration/resolvers.html">changing pattern</a> to 
use for all your modules.
-<li>automatically create a new version for each</li> 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 <a 
href="ivyfile/dependency.html">express a version constraint</a>. Usually 
selecting the very latest one (using 'latest.integration' as version 
constraint) is enough.
-</ul>
-
-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 <b>all</b> 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 
:-)
-
-<h1>Inlining dependencies or not?</h1>
-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:
-<ul>
-<li>separate revision cycle</li> 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
-<li>possibility to publish</li> 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
-<li>more flexible</li> 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
-</ul>
-On the other hand, using inline dependencies is very useful when:
-<ul>
-<li>you want to use a custom task in your ant build</li> 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.
-<li>you want to easily deploy an application</li> 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 <b>any</b> 
version of your application available in your repository!
-</ul>
-<h1>Hire an expert</h1>
-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.
-
-<h1>Feedback</h1>
-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.
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/compatibility.html
----------------------------------------------------------------------
diff --git a/doc/compatibility.html b/doc/compatibility.html
deleted file mode 100644
index 65a0244..0000000
--- a/doc/compatibility.html
+++ /dev/null
@@ -1,51 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 0};</script>   
-       <script type="text/javascript" src="xooki/xooki.js"></script>
-</head>
-<body>
-       <textarea id="xooki-source">
-<h1>JVM compability</h1>
-
-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.
-
-<h1>Apache Ant</h1>
-
-Ivy doesn't require a specific version of Ant as long as the Ant being used 
complies with the JVM compatibility requirements noted above.
-
-<h1>Other optional dependencies</h1>
-
-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 
<tt>org.apache.ivy#ivy</tt> in the Maven Central repository.
-
-<h1>Environment / Configuration Requirements</h1>
-
-Ivy does not at this time support multithreaded use. It thus should not be 
used with the ant <tt>&lt;parallel&gt;</tt> task.
-
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/concept.html
----------------------------------------------------------------------
diff --git a/doc/concept.html b/doc/concept.html
deleted file mode 100644
index 74463c3..0000000
--- a/doc/concept.html
+++ /dev/null
@@ -1,313 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 0};</script>   
-       <script type="text/javascript" src="xooki/xooki.js"></script>
-</head>
-<body>
-       <textarea id="xooki-source">
-<h1><a name="dependency-resolver"></a>Dependency Resolver</h1>
-A dependency resolver is a pluggable class in ivy which is used to:
-<ul>
-<li>find dependencies' ivy files</li>
-<li>download dependencies' artifacts</li>
-</ul>
-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 <a 
href="settings/resolvers.html">resolvers configuration page</a>.
-
-<h1><a name="configurations">Module configurations explained</a></h1>
-Module configurations are described in the terminology page as <em>a way to 
use or construct a module</em>. Configurations being a central part of Ivy, 
they need more explanations as a concept.
-<br/>
-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 <strong>configuration mapping</strong>.
-
-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 <a href="ivyfile.html">ivy file 
documentation</a>. The <a href="tutorial/conf.html">configurations tutorial</a> 
is also a good place to go to learn more about this concept.
-
-<h1><a name="variables"></a>Variables</h1>
-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:
-${<i>variablename</i>}
-where <i>variablename</i> 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, <strong>any later modification of the 
variable will not alter the value already substituted</strong>.
-
-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 [[ant]]), 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.
-<h1><a name="patterns"></a>Patterns</h1>
-
-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]<br/><br/>
-
-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:
-<ul>
-<li>[organisation]</li> the organisation name
-<li>[orgPath] <span class="since">(since 2.3)</span></li> the organisation 
name where '.' has been replaced by '/'. This can be used to configure 
maven2-like repositories. 
-<li>[module]</li> the module name
-<li>[branch]</li> the branch name
-<li>[revision]</li> the revision name
-<li>[artifact]</li> the artifact name (or id)
-<li>[type]</li> the artifact type
-<li>[ext]</li> the artifact file extension
-<li>[conf]</li> the configuration name
-<li>[originalname] <span class="since">(since 1.4)</span></li> the original 
artifact name (including the extension)
-</ul>
-
-The difference between type and extension is explained in the ivy file 
documentation.
-
-<span class="since">since 1.2</span> [organization] can be used instead of 
[organisation].
-
-<span class="since">since 1.3</span> 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 <code>[artifact](-[revision]).[ext]</code> 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.
-
-<span class="since">since 1.4</span> Extra attributes can be used as any other 
token in a pattern.
-
-<h1><a name="latest">Latest Strategy</a></h1>
-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:
-<ul>
-<li>latest-time</li> 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.
-<li>latest-revision</li> 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.
-<li>latest-lexico</li> This compares the revisions as strings, using 
lexicographic order (the one used by the Java string comparison).
-</ul>
-
-See also how to configure new latest strategies <a 
href="settings/latest-strategies.html">here</a>.
-
-<h1><a name="conflict">Conflict Manager</a></h1>
-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 <a 
href="settings/conflict-managers.html">conflict manager configuration page</a>.
-
-For more details on how to setup your conflict managers by module, see the <a 
href="ivyfile/conflicts.html">conflicts</a> section in the ivy file reference.
-
-<h1><a name="matcher">Pattern matcher</a></h1>
-<span class="since">since 1.3</span>
-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:
-<ul>
-<li>exact</li>This matcher matches only using strings
-<li>regexp</li>This matcher lets you use a regular expression as supported by 
the Pattern class of java 1.4 or greater
-<li>glob</li>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.
-</ul>
-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.
-
-<h1><a name="extra">Extra attributes</a></h1>
-<span class="since">since 1.4</span>
-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.
-
-<span class="since">since 2.0</span>
-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:
-<code type="xml">
-<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>
-</code>
-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:
-<code>
-<dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
-</code>
-And you can define your repository pattern as:
-<code>
-${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
-</code>
-
-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 <a href="settings/settings.html">settings 
documentation</a> to see how to disable validation.
-<h1><a name="checksum">Checksums</a></h1>
-<span class="since">since 1.4</span>
-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 "".
-
-<h2>Supported algorithms</h2>
-<span class="since">since 1.4</span>
-               <ul>
-                       <li>md5</li>
-                       <li>sha1</li>
-               </ul>
-<span class="since">since 2.5</span>
-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.
-
-<h1><a name="event">Events and Triggers</a></h1>
-<span class="since">since 1.4</span>
-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 <a 
href="settings/triggers.html">triggers</a> documentation page in the 
configuration section of this documentation.
-
-<h1><a name="circular">Circular Dependencies</a></h1>
-<span class="since">since 1.4</span>
-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:
-<ul>
-<li>ignore</li> circular dependencies are only signaled in verbose messages
-<li>warn</li> same as ignore, except that they are signaled as a warning 
(default)
-<li>error</li> halt the dependency resolution when a circular dependency is 
found
-</ul>
-
-See the <a href="settings/settings.html">configuration page</a> to see how to 
configure the circular dependency strategy you want to use.
-
-<h1>Cache and Change Management</h1>
-Ivy heavily relies on local caching to avoid accessing remote repositories too 
often, thus saving a lot of network bandwidth and time. 
-
-<h2><a name="cache">Cache types</a></h2>
-An Ivy cache is composed of two different parts:
-<ul>
-<li>the repository cache</li>
-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 
[[settings/lock-strategies lock strategy]]. 
-<li>the resolution cache</li>
-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.
-</ul>
-
-While there is always only one resolution cache, you can [[settings/caches 
define multiple repository caches]], each [[settings/resolvers resolver]] being 
able to use a separate cache.
-
-<h2><a name="change">Change management</a></h2>
-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 [[bestpractices 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:
-<h3>Changes in module metadata</h3>
-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.
-<h3>Changes in artifacts</h3>
-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 [[ivyfile/dependency]] tag, or use the 
changingPattern and changingMatcher attributes on your [[settings/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 [[ant: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!
-<h1><a name="paths">Paths handling</a></h1>
-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 
<code>${ivy.basedir}/ivy.xml</code>, you have an absolute path. In [[settings 
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:
-<ul>
-<li>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)</li>
-<li>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.</li>
-<li>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.</li>
-</ul>
-
-<h1><a name="packaging">Packaging</a></h1>
-
-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 <i>unpacking</i> 
after being downloaded and before being used. Such artifacts can be zipped 
folders and packed jars. Ivy supports that kind of artifact with 
<b>packaging</b>.
-
-A <i>packaged</i> artifact needs to be declared as such in the module 
descriptor via the attribute <a href="ivyfile/artifact.html">packaging</a>. The 
value of that attribute defined which kind of unpacking algorithm must be used. 
Here are the list of currently supported algorithms:
-<ul>
-    <li><tt>zip</tt>, <tt>jar</tt> or <tt>war</tt>: the artifact will be 
uncompressed as a folder</li>
-    <li><tt>pack200</tt>: the artifact will be unpacked to a file via the <a 
href="http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html";>pack200</a>
 algorithm</li>
-    <li><tt>bundle</tt>: the OSGi artifact will be uncompressed as a folder, 
and every embedded jar file entry which is packed via the the <a 
href="http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html";>pack200</a>
 algorithm will be unpacked</li>
-</ul>
-
-So, if in an <tt>ivy.xml</tt>, there would be declared a such artifact:
-<code>
-    <artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200" 
/>
-</code>
-A file <tt>mymodule-1.2.3.jar.pack.gz</tt> would be download into the cache, 
and also uncompressed in the cache to <tt>mymodule-1.2.3.jar</tt>. Then any 
post resolve task which supports it, like the <a 
href="use/cachepath.html">cachepath</a>, will use the uncompressed file instead 
of the orginal compressed file.
-
-It is possible to chain packing algorithm. The attribute <a 
href="ivyfile/artifact.html">packaging</a> of a artifact expects a comma 
separated list of packing types, in packing order. For instance, an artifact 
'<tt>mymodule-1.2.3.jar.pack.gz</tt>' can have the packaging 
'<tt>jar,pack200</tt>', so it would be uncompressed as a folder 
'<tt>mymodule-1.2.3</tt>'.
-
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/config.js
----------------------------------------------------------------------
diff --git a/doc/config.js b/doc/config.js
deleted file mode 100644
index c9e32f8..0000000
--- a/doc/config.js
+++ /dev/null
@@ -1,8 +0,0 @@
-xooki.util.mix({debug:true, 
-       jira: {ids: ['IVY'], url: 'https://issues.apache.org/jira'}, 
-       shortcuts: {
-               gitdir: {pre: 
'https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tree;f='},
-               gitfile: {pre: 
'https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f='},
-               ant: {pre: xooki.c.relativeRoot+'use/', post:'.html'}
-       }
-}, xooki.c, false);

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/configuration.html
----------------------------------------------------------------------
diff --git a/doc/configuration.html b/doc/configuration.html
deleted file mode 100644
index ad4aeea..0000000
--- a/doc/configuration.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 0};</script>   
-       <script type="text/javascript" src="xooki/xooki.js"></script>
-       <meta HTTP-EQUIV="REFRESH" content="3; url=settings.html">
-</head>
-<body>
-<textarea id="xooki-source">
-This page has moved. If your browser doesn't automatically redirect to its new 
location, click
-<a href="settings.html">here</a>.
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/configuration/caches.html
----------------------------------------------------------------------
diff --git a/doc/configuration/caches.html b/doc/configuration/caches.html
deleted file mode 100644
index 3c4483c..0000000
--- a/doc/configuration/caches.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 1};</script>   
-       <script type="text/javascript" src="../xooki/xooki.js"></script>
-       <meta HTTP-EQUIV="REFRESH" content="3; url=../settings/caches.html">
-</head>
-<body>
-<textarea id="xooki-source">
-This page has moved. If your browser doesn't automatically redirect to its new 
location, click
-<a href="../settings/caches.html">here</a>.
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/configuration/caches/cache.html
----------------------------------------------------------------------
diff --git a/doc/configuration/caches/cache.html 
b/doc/configuration/caches/cache.html
deleted file mode 100644
index f87f783..0000000
--- a/doc/configuration/caches/cache.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 2};</script>   
-       <script type="text/javascript" src="../../xooki/xooki.js"></script>
-       <meta HTTP-EQUIV="REFRESH" content="3; 
url=../../settings/caches/cache.html">
-</head>
-<body>
-<textarea id="xooki-source">
-This page has moved. If your browser doesn't automatically redirect to its new 
location, click
-<a href="../../settings/caches/cache.html">here</a>.   
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/configuration/caches/ttl.html
----------------------------------------------------------------------
diff --git a/doc/configuration/caches/ttl.html 
b/doc/configuration/caches/ttl.html
deleted file mode 100644
index 0b53fbc..0000000
--- a/doc/configuration/caches/ttl.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 2};</script>   
-       <script type="text/javascript" src="../../xooki/xooki.js"></script>
-       <meta HTTP-EQUIV="REFRESH" content="3; 
url=../../settings/caches/ttl.html">
-</head>
-<body>
-<textarea id="xooki-source">
-This page has moved. If your browser doesn't automatically redirect to its new 
location, click
-<a href="../../settings/caches/ttl.html">here</a>.     
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/configuration/classpath.html
----------------------------------------------------------------------
diff --git a/doc/configuration/classpath.html b/doc/configuration/classpath.html
deleted file mode 100644
index 0493469..0000000
--- a/doc/configuration/classpath.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd";>
-<!--
-   Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.    
--->
-<html>
-<head>
-       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-       <script type="text/javascript">var xookiConfig = {level: 1};</script>   
-       <script type="text/javascript" src="../xooki/xooki.js"></script>
-       <meta HTTP-EQUIV="REFRESH" content="3; url=../settings/classpath.html">
-</head>
-<body>
-<textarea id="xooki-source">
-This page has moved. If your browser doesn't automatically redirect to its new 
location, click
-<a href="../settings/classpath.html">here</a>.
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

Reply via email to