http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/build-repository/advanced.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/build-repository/advanced.html 
b/doc/tutorial/build-repository/advanced.html
deleted file mode 100644
index 112ad6e..0000000
--- a/doc/tutorial/build-repository/advanced.html
+++ /dev/null
@@ -1,118 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-Now that you have seen how simple it is to create your own repository from an 
existing one, you may wonder how you can handle more complex cases, like when 
the source and destination repositories don't follow the same naming 
conventions. 
-
-
-<h1>On the road to a professional repository</h1>
-In this section, you will learn how to build a <strong>professional</strong> 
repository. What is a <strong>professional</strong> repository? Our vision is 
to say that a good quality repository must follow clear rules about projects 
naming and must offer correct, useable, configurations and verified project 
descriptors. In order to achieve those goals, we think that you have to build 
your own repository.
-We have seen in the previous example, that we could use some public 
repositories to begin to build our own repository. Nevertheless, the result is 
not always the expected one, especially concerning the naming rules used.
-
-This problem is pretty normal when you have an existing repository, and want 
to benefit from large public repositories which do not follow the same naming 
conventions. It also shows up because many public repositories do not use a  
consistent naming scheme. For example, why don't all the apache commons modules 
use the org.apache.commons organization? Well.. for historical reasons. But if 
you setup your own repository, you may not want to suffer from the mistakes of 
history.
-
-Fortunately, Ivy has a very powerful answer to this problem: 
[[settings/namespaces namespaces]].
-
-<h1>Using namespaces</h1>
-If you look at the repository built with the [[tutorial/build-repository/basic 
previous tutorial]], you will see exactly what we were talking about: all 
apache commons modules use their own name as their organization.
-
-So let's see what Ivy can do using namespaces (we will dig into details later):
-<div class="shell"><pre>
-[<tutorial/log/install-namespace.txt>]
-</pre></div>
-
-Now if we look at our repository, it seems to look fine.
-<div class="shell"><pre>
-[<tutorial/log/myrepository-content-namespace.txt>]
-</pre></div>
-We can even have a look at the commons-lang ivy file in our repository:
-<div><code type="xml">
-<?xml version="1.0" encoding="UTF-8"?>
-<ivy-module version="1.0">
-       <info organisation="apache"
-               module="commons-lang"
-               revision="1.0"
-               status="integration"
-               publication="20051124062021"
-               namespace="ibiblio-maven2"
-       />
-
-...
-</code></div>
-Alright, we see that the organisation is now 'apache'. But where did Ivy pick 
this up?
-<h2>How does this work ?</h2>
-Actually, Ivy uses the same repository as before for the source repository, 
with only one difference: the namespace parameter:
-<code type="xml">
-<ibiblio name="libraries" 
-    root="${ibiblio-maven2-root}" 
-    m2compatible="true"
-    namespace="maven2"
-/>
-</code>
-
-A namespace is defined by a set of rules. These rules are based on regular 
expressions and tell Ivy how to convert data from the repository namespace  to 
what is called the system namespace, i.e. the namespace in which Ivy runs most 
of the time (Note: the Ivy cache always uses the system namespace).
-
-For the namespace we call <i>maven2</i>, we have declared several rules. Below 
is one of the rules:
-<h3>rule handling the imported apache maven1 projects</h3>
-<code type="xml"><rule>        <!-- imported apache maven1 projects -->
-       <fromsystem>
-           <src org="apache" module=".+"/>
-           
-           <dest org="$m0" module="$m0"/>
-       </fromsystem>
-       <tosystem>
-           <src org="commons-.+" module="commons-.+" />
-           <src org="ant.*" module="ant.*" />
-           ...
-           <src org="xmlrpc" module="xmlrpc" />
-
-           <dest org="apache" module="$m0"/>
-       </tosystem>
-</rule></code>
-<div class="postit"><u>Note about regular expressions usage :</u>
-In order to distinguish matching regular expressions found in organization, 
module, and revision, the notation Ivy uses prefixes the matching regular 
expression with the letters 'o', 'm' and 'r'.
-$o0 : the whole matching value in the organization attribute
-$o1 : the first matching expression group that was marked in the organization 
attribute
-...
-The same applies for modules : $m0, $m1, ...
-and for revisions : $r0, $r1, ...
-</div>
-To understand namespaces, 
-<ul>
-<li><b>fromsystem :</b> we define here that the projects defined in the system 
namespace under the organization called "apache" are transformed into the 
destination namespace into projects whose organization is named with the module 
name, whatever the revision is. For example, the project 
apache#commons-lang;1.0  in the system namespace will be translated into 
commons-lang#commons-lang;1.0 in the maven2 resolver namespace.</li>
-<li><b>tosystem :</b> we define here the reverse mapping, i.e. how to 
translate <em>apache</em> projects from maven 2 repo into apache projects in 
the system namespace. The rule used here tells Ivy that all projects matching 
<tt>commons-.+</tt> (see it as java regular expression) for their organization 
name and module name are transformed into projects whose organisation is 
<tt>apache</tt> with the module name as it was found. The same kind of rule is 
defined for others apache projects like ant, etc.</li>
-</ul>
-
-OK, you should now get the idea behind namespaces, so go ahead and look at the 
<tt>ivysettings-advanced.xml</tt> file in this example. You can test the 
installation of a module and its dependencies using namespaces.
-
-Run 
-<code>ant maven2-namespace-deps</code> 
-and you will see the resulting repository is cleaner than the first one we 
built.
-
-From our experience, investing in creating a namespace is worth the time it 
costs if you often need to add new modules or revisions of third party 
libraries in your own repository, where naming rules already exist or are 
rather strict. </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/build-repository/basic.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/build-repository/basic.html 
b/doc/tutorial/build-repository/basic.html
deleted file mode 100644
index 9f1c566..0000000
--- a/doc/tutorial/build-repository/basic.html
+++ /dev/null
@@ -1,108 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-In this first step, we use the [[ant:install]] Ant task to install modules 
from the maven 2 repository to a file system based repository. We first install 
a module by itself, excluding dependencies, then again with its dependencies.
-
-<h1>Basic: ivysettings.xml file used</h1>
-The ivy settings file that we will use is very simple here. It defines two 
resolvers, <i>libraries</i> and <i>my-repository</i>. The first one is used as 
the source, the second one as the destination. In a typical setup, the second 
one would be configured using an [[settings/include include]] that included an 
existing settings file used by the development team.
-
-<code type="xml">
-<ivysettings>
-       <settings       defaultResolver="libraries"
-                       defaultConflictManager="all" />         <!-- in order 
to get all revisions without any eviction -->
-       <caches defaultCacheDir="${ivy.cache.dir}/no-namespace" />
-       <resolvers>
-               <ibiblio name="libraries" m2compatible="true" />
-               <filesystem name="my-repository">
-                       <ivy 
pattern="${dest.repo.dir}/no-namespace/[organisation]/[module]/ivys/ivy-[revision].xml"/>
-                       <artifact 
pattern="${dest.repo.dir}/no-namespace/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
-               </filesystem>
-       </resolvers>
-</ivysettings>
-</code>
-
-<h1>install a simple module with no dependencies</h1>
-Let's have a look at the <em>maven2</em> target.
-<code type="xml">
-    <target name="maven2" depends="init-ivy"
-       description="--> install module from maven 2 repository">
-       <ivy:install settingsRef="basic.settings" 
-               organisation="commons-lang" module="commons-lang" 
revision="1.0" 
-               from="${from.resolver}" to="${to.resolver}" />
-    </target>
-</code>
-Pretty simple, we call the [[ant:install] task with the settings we have 
loaded using [[ant:settings ivy:settings]] as usual. We then set the source and 
destination repositories using the <i>from</i> and <i>to</i> attributes. We 
used Ant properties for these values here, which helps ease the maintenance of 
the script, but it's basically the name of our resolvers: 'libraries' for the 
source and 'my-repository' for the destination.
-
-Here is the Ant call output :
-<div class="shell"><pre>
-[<tutorial/log/install.txt>]
-</pre></div>
-The trace tells us that the module definition was found using the "libraries" 
resolver and that the corresponding artifact was downloaded from the maven 2 
repository. Then both were published to the filesystem repository 
(my-repository).
-
-Let's have a look at our repository :
-<div class="shell"><pre>
-[<tutorial/log/myrepository-content.txt>]
-</div>
-We can see that we now have the commons-lang module version 1.0 in our 
repository, with a generated ivy.xml file, its jar, and all the md5 and sha1 
checksums for future consistency checks when developers use this repository to 
resolve modules.
-
-<h1>install a module with dependencies</h1>
-Now let's say that we want to be sure all the dependencies of the module we 
install are available in our repository after the installation. We could either 
install without dependencies on a staging repository and check the missing 
dependencies (more control), or use transitive dependency management and ask 
Ivy to install everything for us (much simpler).
-
-The <tt>maven2-deps</tt> target is very similar to the one described above, 
except that we explicitly ask for transitive installation.
-<code type="xml">
-    <target name="maven2-deps" depends="init-ivy" 
-       description="--> install module from maven 2 repository with 
dependencies">
-       <ivy:install settingsRef="basic.settings" 
-               organisation="org.hibernate" module="hibernate" 
revision="3.2.5.ga" 
-               from="${from.resolver}" to="${to.resolver}" transitive="true" />
-    </target>
-</code>
-
-If you call this target, you will see that Ivy installs not only the hibernate 
module but also its dependencies:
-<div class="shell"><pre>
-[<tutorial/log/install-deps.txt>]
-</pre>
-</div>
-
-As you can see the installation has failed, if you look at the log you will 
see that there are missing artifacts on the source repository. This means that 
you will need to download those artifacts manually, and copy them to your 
destination repository to complete the installation. Fortunately Ivy uses a 
best effort algorithm during install, so that everything gets installed except 
the missing artifacts. (Note: these missing artifacts are not in the public 
maven repository due to licensing issues)
-
-You may also have noticed that Ivy installed 2 different revisions of 
commons-logging (1.0.2, 1.0.4). This is due to the fact that we used the "no 
conflict" [[settings/conflict-managers conflict manager]] in the ivysettings 
file.
-
-We do not want to evict any modules because we are building our own 
repository. Indeed if we get both commons-logging 1.0.2 and 1.0.4 it's because 
some modules among the transitive dependencies of hibernate depend on 1.0.2 and 
others on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 would be 
inconsistent in your own repository (depending on a version you don't have 
installed). Thus developers using this module directly would run into a problem.
-
-If you now have a closer look at your repository, you will probably notice 
that it isn't an exact replication of the original one. Let's have a look at 
the directory of one module:
-<div class="shell"><pre>
-[<tutorial/log/myrepository-content-deps.txt>]
-</pre>
-</div>
-
-As you can see there is no pom here (pom is the module metadata format used by 
maven 2, available on the maven 2 repository). Instead you can see there's an 
ivy file, which is actually the original hibernate pom converted into an ivy 
file. So now you have a true Ivy repository with ivy files, where you can use 
the full power of Ivy if you want to adjust the module metadata (module 
configurations, fine grain exclusions and transitivity control, per module 
conflict manager, ...).
-
-OK, enough for this simple repository installation, the 
[[tutorial/build-repository/advanced next tutorial]] will show how you can deal 
with more complex cases where your source and destination repositories do not 
follow the same naming conventions.</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/conf.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/conf.html b/doc/tutorial/conf.html
deleted file mode 100644
index ec12fa0..0000000
--- a/doc/tutorial/conf.html
+++ /dev/null
@@ -1,173 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-This tutorial introduces the use of module configurations in ivy files. Ivy 
module configurations are indeed a very important concept. Someone even told me 
one day that using Ivy without using configurations is like eating a good 
cheese without touching the glass of Chateau Margaux 1976 you have just poured 
:-)
-
-More seriously, configurations in Ivy can be better understood as views on 
your module, and you will see how they can be used effectively here.
-
-Reference documentation on configurations can be found <a 
href="../terminology.html">here</a> and <a 
href="../ivyfile/configurations.html">here</a>.
-<h1>Introduction</h1>
-Source code is available in <tt>src/example/configurations/multi-projects</tt>.
-We have two projects :
-  - filter-framework is a library that defines an api to filter String arrays 
and two implementations of this api.
-  - myapp is a very small app that uses filter-framework.
-  
-The filter-framework library project produces 3 artifacts:
-  - the api jar,
-  - an implementation jar with no external dependencies,
-  - a second implementation jar that needs commons-collections to perform.
-
-The application only needs the api jar to compile and can use either of the 
two implementations at runtime.
-
-<h1>The library project</h1>
-The first project we'll look at in this tutorial is filter-framework. In order 
to have a fine-grained artifacts publication definition, we defined several 
configurations, each which maps to a set of artifacts that other projects can 
make use of.
-<h2>The ivy.xml file</h2>
-
-<div class="ivy-file">
-<code type="xml">
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="filter-framework"/>
-    <configurations>
-       <conf name="api"  description="only provide filter framework API"/>
-       <conf name="homemade-impl" extends="api" description="provide a home 
made implementation of our api"/>
-       <conf name="cc-impl" extends="api" description="provide an 
implementation that use apache common collection framework"/>
-       <conf name="test" extends="cc-impl" visibility="private" 
description="for testing our framework"/>
-    </configurations>
-    <publications>
-       <artifact name="filter-api" type="jar"  conf="api" ext="jar"/>
-       <artifact name="filter-hmimpl" type="jar"  conf="homemade-impl" 
ext="jar"/>
-       <artifact name="filter-ccimpl" type="jar"  conf="cc-impl" ext="jar"/>   
        
-    </publications>
-    <dependencies>
-        <dependency org="commons-collections" name="commons-collections" 
rev="3.1" conf="cc-impl->default"/>
-        <dependency org="junit" name="junit" rev="3.8" conf="test->default"/>
-    </dependencies>
-</ivy-module>
-</code> 
-</div>
-<h2>Explanation</h2>
-As you can see, we defined 4 configurations, with 3 being public and 1 
private. (the  junit dependency for testing).
-The 2 implementation configurations, <b>homemade-impl</b> and <b>cc-impl</b> 
extend the <b>api</b> configuration so that all artifacts defined in <b>api</b> 
will also be part of the extending configuration.
-
-In the publications tag, we defined the artifacts we produce (jars in this 
case) and we assign them to a configuration. When others use our library they 
will have a flexible way to ask for what they need.
-
-<h2>See it in action</h2>
-The filter-framework project is built using Ant. Open a shell in the root 
directory of the project and type <tt>ant</tt>.
-<div class="shell"><pre>
-[<tutorial/log/configurations-lib.txt>]
-</pre></div>
-The Ant default target is publish. This target uses Ivy to publish our library 
binaries to a local repository. Since we do not specify any repository path, 
the default one is used. 
(<tt>${home.dir}/.ivy2/local/org.apache/filter-framework/</tt>) At this point, 
we are ready to use our library.
-
-<h1>The application project</h1>
-
-Now that we have shipped (published) our fantastic filter library, we want to 
use it! The tutorial comes with a sample application called myapp.
-<h2>The <tt>ivy.xml</tt> file</h2>
-
-<div class="ivy-file">
-<code type="xml">
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="myapp"/>
-    
-    <configurations>
-               <conf name="build" visibility="private" 
description="compilation only need api jar" />
-       <conf name="noexternaljar" description="use only company jar" />
-       <conf name="withexternaljar" description="use company jar and third 
party jars" />    
-    </configurations>
-    
-    <dependencies>
-        <dependency org="org.apache" name="filter-framework" 
rev="latest.integration" conf="build->api; noexternaljar->homemade-impl; 
withexternaljar->cc-impl"/>
-    </dependencies>
-</ivy-module>
-</code> 
-</div>
-<h2>Explanation</h2>
-We create 3 configurations that define the different ways we want to use the 
application. The <b>build</b> configuration defines the compile-time 
dependencies, and thus only needs the api conf from the filter-framework 
project. The other two configurations define runtime dependencies. One will 
only use our "home-made" jar, and the other will use an external jar.
-
-We also defined a dependency on our previously built library. In this 
dependency, we use configuration mappings to match ours with the dependency's 
configurations. You can find more information about configuration mapping <a 
href="../ivyfile/configurations.html">here</a>
-<ol>
-  <li><b>build->api</b> : here we tell Ivy that our <b>build</b> configuration 
depends on the <b>api</b> configuration of the dependency</li>
-  <li><b>noexternaljar->homemade-impl</b> : here we tell Ivy that our 
<b>noexternaljar</b> configuration depends on the <b>homemade-impl</b> 
configuration of the dependency.</li>
-  <li><b>withexternaljar->cc-impl</b> : here we tell Ivy that our 
<b>withexternaljar</b> configuration depends on the <b>cc-impl</b> 
configuration of the dependency</li>
-</ol>
-Note that we never declare any of the dependency's artifacts we need in each 
configuration: it's the dependency module's ivy file which declares the 
published artifacts and which should be used in each configuration.
-
-In the Ant <tt>build.xml</tt> file, we defined a 'resolve' target as follow:
-
-<code type="xml">
-<target name="resolve" description="--> retreive dependencies with ivy">
-    <ivy:retrieve pattern="${ivy.lib.dir}/[conf]/[artifact].[ext]"/>
-</target>    
-</code> 
-
-When we call this target, Ivy will do a resolve using our <tt>ivy.xml</tt> 
file in the root folder and then retrieve all the artifacts. The artifacts 
retrieved are kept in separate folders according to the configurations they 
belong to. Here is how your lib directory should look after a call to this 
target:
-<div class="shell"><pre>
- Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib
-
-01/24/2006  11:19 AM    <REP>          build
-01/24/2006  11:19 AM    <REP>          noexternaljar
-01/24/2006  11:19 AM    <REP>          withexternaljar
-               0 fichier(s)                0 octets
-
- Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib\build
-
-01/24/2006  10:53 AM             1,174 filter-api.jar
-               1 fichier(s)            1,174 octets
-
- Repertoire de 
D:\ivy\src\example\configurations\multi-projects\myapp\lib\noexternaljar
-
-01/24/2006  10:53 AM             1,174 filter-api.jar
-01/24/2006  10:53 AM             1,030 filter-hmimpl.jar
-               2 fichier(s)            2,204 octets
-
- Repertoire de 
D:\ivy\src\example\configurations\multi-projects\myapp\lib\withexternaljar
-01/24/2006  10:53 AM           559,366 commons-collections.jar
-01/24/2006  10:53 AM             1,174 filter-api.jar
-01/24/2006  10:53 AM             1,626 filter-ccimpl.jar
-               3 fichier(s)          562,166 octets
-</pre></div>
-As you can see, for each configuration we have now a set of jars.
-
-Let's try to launch our app.
-
-<h2>See it in action</h2>
-Use Ant to run the application. The default Ant target is <i>run-cc</i> and 
will launch the application using the Apache commons-collections implementation.
-<div class="shell"><pre>
-[<tutorial/log/configurations-runcc.txt>]
-</pre></div>
-Launching the application using the homemade implementation is also 
straightforward.
-type <tt>ant run-hm</tt>
-
-<div class="shell"><pre>
-[<tutorial/log/configurations-runhm.txt>]</pre></div>
-Nice! We got the same result, but we can see that the implementation classes 
are different.
-
-<h1>Conclusion</h1>
-<b>You should use configurations as often as possible.</b> Configurations are 
a very important concept in Ivy. They allow you to group artifacts and give the 
group a meaning. When you write ivy files for projects that are intended for 
use by others, use configurations to allow people to get only what they need, 
without having to specify them one by one in their own dependency list. 
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/defaultconf.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/defaultconf.html b/doc/tutorial/defaultconf.html
deleted file mode 100644
index 378accd..0000000
--- a/doc/tutorial/defaultconf.html
+++ /dev/null
@@ -1,216 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-Ivy comes bundled with some default settings which makes it pretty simple to 
use in a typical environment. This tutorial, which is close to a reference 
document, explains what those default settings are and how they can be adjusted 
to your needs. 
-
-To fully understand the concept of settings and what you can do with them, we 
suggest reading other tutorials related to settings (like [[tutorial/multiple]] 
and [[tutorial/dual]]) or the [[settings]] reference documentation.
-
-<h1>Concept</h1>
-The default settings include 3 types of repositories:
-<ul>
-<li>local</li> a repository which is private to the user. 
-<li>shared</li> a repository which is shared between all the members of a team
-<li>public</li> a public repository on which most modules, and especially 
third party modules, can be found
-</ul>
-
-Note that if you work alone, the distinction between a local and shared 
repository is not very important, but there are some things you should know to 
distinguish them.
-
-Now let's describe each of these repository concepts in more detail. We will 
describe how they are set up physically later.
-<h2>Local</h2>
-The local repository is particularly useful when you want to do something 
without being disturbed by anything else happening in the environment. This 
means that whenever Ivy is able to locate a module in this repository it will 
be used, no matter what is available in others.
-
-For instance, if you have a module declaring a dependency on the module 
<i>foo</i> with a revision of <i>latest.integration</i>, then if a revision of 
<i>foo</i> is found in the local repository, it will be used, <em>even if a 
more recent revision is available in other repositories</em>. 
-
-This may be disturbing for some of you, but imagine you have to implement a 
new feature on a project, and in order to achieve that you need to modify two 
modules: you add a new method in module <i>foo</i> and exploit this new method 
in module <i>bar</i>. Then if you publish the module <i>foo</i> to your local 
repository, you will be sure to get it in your <i>bar</i> module, even if 
someone else publishes a new revision of <i>foo</i> in the shared repository 
(this revision not having the new method you are currently adding).
-
-But be careful, when you have finished your development and publish it on the 
shared repository, you will have to clean your local repository to benefit from 
new versions published in the shared repository.
-
-Note also that modules found in the local repository must be complete, i.e. 
they must provide both a module descriptor and the published artifacts. 
-<h2>Shared</h2>
-As its name suggest, the shared repository is aimed to be shared among a whole 
development team. It is a place where you can publish your team's private 
modules, and it's also a place where you can put modules not available in the 
public repository (sun jars, for instance). You can also put modules here that 
are simply inaccurate in a public repository (bad or incomplete module 
descriptors for instance).
-
-Note that modules can be split across the shared repository and the public 
one: For example, you can have the module descriptor in the shared repository 
and the artifacts in the public one.
-<h2>Public</h2>
-The public repository is the place where most modules can be found, but which 
sometimes lack the information you need. It's usually a repository available 
through an internet connection only, even if this is not mandatory.
-<h1>Setting up the repositories</h1>
-Now that we have seen the objective of each of the three repositories, let's 
see how they are setup and how to configure them to fit your needs.
-
-First, several repositories use the same root in your filesystem. Referenced 
as <tt>${ivy.default.ivy.user.dir}</tt>, this is by default the directory 
<tt>.ivy2</tt> in your user home.
-
-Note that several things can be done by setting Ivy variables. To set them 
without defining your own <tt>ivysettings.xml</tt> file, you can:<ul>
-<li>set an Ant property before any call to Ivy in your build file if you use 
Ivy from Ant</li>
-<li>set an environment variable if you use Ivy from the command line</li>
-</ul>
-For example:
-<code type="xml">
-<target name="resolve">
-  <property name="ivy.default.ivy.user.dir" value="/path/to/ivy/user/dir"/>
-  <ivy:resolve />
-</target>
-</code>
-
-Next we will show you how to override default values for the different kinds 
of repositories. Note that you can find what the default values are below in 
the details of the default settings.
-<h2>Local</h2>
-By default, the local repository lies in 
<tt>${ivy.default.ivy.user.dir}/local</tt>. This is usually a good place, but 
you may want to modify it. No problem, you just have to set the following Ivy 
variable to the directory you want to use: <code>ivy.local.default.root</code>. 
For instance:
-<code>ivy.local.default.root=/opt/ivy/repository/local</code>.
-
-If you already have something you would like to use as your local repository, 
you may also want to modify the layout of this repository. Once again, two 
variables are available for that:
-<code>ivy.local.default.ivy.pattern</code> gives the pattern to find ivy files
-<code>ivy.local.default.artifact.pattern</code> gives the pattern to find 
artifacts
-For example:
-<code>
-ivy.local.default.root=/opt/ivy/repository/local
-ivy.local.default.ivy.pattern=[module]/[revision]/ivy.xml
-ivy.local.default.artifact.pattern=[module]/[revision]/[artifact].[ext]
-</code>
-<h2>Shared</h2>
-By default, the shared repository lies in 
<tt>${ivy.default.ivy.user.dir}/shared</tt>. This is fine if you work alone, 
but the shared repository is supposed to be, mmm, shared! So changing this 
directory is often required, and it is usually modified to point to a network 
shared directory. You can use the <code>ivy.shared.default.root</code> variable 
to specify a different directory. Moreover, you can also configure the layout 
with variables similar to the ones used for the local repository:
-<code>ivy.shared.default.ivy.pattern</code> gives the pattern to find ivy files
-<code>ivy.shared.default.artifact.pattern</code> gives the pattern to find 
artifacts
-For example:
-<code>
-ivy.shared.default.root=/opt/ivy/repository/shared
-ivy.shared.default.ivy.pattern=[organisation]/[module]/[revision]/ivy.xml
-ivy.shared.default.artifact.pattern=[organisation]/[module]/[revision]/[artifact].[ext]
-</code>
-
-<h2>Public</h2>
-By default, the public repository is ibiblio in m2 compatible mode (in other 
words, the maven 2 public repository).
-
-This repository has the advantage of providing a lot of modules, with metadata 
for most of them. The quality of metadata is not always perfect, but it's a 
very good start to use a tool like Ivy and benefit from the power of transitive 
dependency management. 
-
-Despite its ease of use, we suggest reading the [[bestpractices]] to have a 
good understanding of the pros and cons of using a public unmanaged repository 
before depending on such a repository for your enterprise build system.
-
-<em>In 1.4 version Ivy was using ivyrep as the default resolver, if you want 
to restore this, set
-ivy.14.compatible=true as an ant property</em>
-
-<h1>Going further</h1>
-OK, so we have seen how to easily change the settings of the three main 
repositories. But what if my shared repository is on a web server? What if you 
don't want to use maven 2 repository as the public repository? What if ... 
-
-No problem, Ivy is very flexible and can be configured with specific settings 
to match your needs and environment. But before considering writing your own 
settings from scratch, we suggest reading the following where you will learn 
how to leverage a part of the default settings and adjust the rest.
-
-But before explaining how, you will need to have a quick overview of how Ivy 
is configured by default.
-
-By default, Ivy is configured using an <tt>ivysettings.xml</tt> which is 
packaged in the Ivy jar. Here is this settings file:
-<code type="xml">
-<ivysettings>
-  <settings defaultResolver="default"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
-</ivysettings>
-</code>
-OK, so not much info here, except a lot of inclusions. These inclusions have 
been done on purpose so that you can easily change only one part of the 
ivysettings and easily benefit from the rest. For example, if you want to 
define your own public resolver, you will just have to configure Ivy with an 
ivysettings like the following:
-<code type="xml">
-<ivysettings>
-  <settings defaultResolver="default"/>
-  <include url="http://myserver/ivy/myivysettings-public.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
-  <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
-</ivysettings>
-</code>
-Note that only the <tt>ivysettings-public.xml</tt> inclusion has changed to 
include a homemade public resolver. Note also that this can be used like that 
thanks to the fact that <tt>${ivy.default.settings.dir}</tt> is a variable 
which is always set to the place where Ivy's default settings files are (i.e. 
packaged in the jar).
-To finish this example, you have to write your own ivysettings file (that you 
will make available at http://myserver/ivy/myivysettings-public.xml in this 
example) for defining your own public resolver. For instance:
-<code type="xml">
-<ivysettings>
-  <resolvers>
-    <filesystem name="public">
-      <ivy 
pattern="/path/to/my/public/rep/[organisation]/[module]/ivy-[revision].xml" />
-      <artifact 
pattern="/path/to/my/public/rep/[organisation]/[module]/[artifact]-[revision].[ext]"
 />
-    </filesystem>
-  </resolvers>
-</ivysettings>
-</code>
-Now the last thing you will need in order to properly take advantage of the 
default settings is the content of each included ivysettings file:
-<strong>ivysettings-public.xml</strong>
-<code type="xml">
-<ivysettings>
-  <resolvers>
-    <ibiblio name="public" m2compatible="true"/>
-  </resolvers>
-</ivysettings>
-</code>
-<strong>ivysettings-shared.xml</strong>
-<code type="xml">
-<ivysettings>
-  <property name="ivy.shared.default.root"             
value="${ivy.default.ivy.user.dir}/shared" override="false"/>
-  <property name="ivy.shared.default.ivy.pattern"      
value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" 
override="false"/>
-  <property name="ivy.shared.default.artifact.pattern" 
value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" 
override="false"/>
-  <resolvers>
-    <filesystem name="shared">
-      <ivy 
pattern="${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern}" />
-      <artifact 
pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}" />
-    </filesystem>
-  </resolvers>
-</ivysettings>
-</code>
-<strong>ivysettings-local.xml</strong>
-<code type="xml">
-<ivysettings>
-  <property name="ivy.local.default.root"             
value="${ivy.default.ivy.user.dir}/local" override="false"/>
-  <property name="ivy.local.default.ivy.pattern"      
value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" 
override="false"/>
-  <property name="ivy.local.default.artifact.pattern" 
value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" 
override="false"/>
-  <resolvers>
-    <filesystem name="local">
-      <ivy 
pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
-      <artifact 
pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
-    </filesystem>
-  </resolvers>
-</ivysettings>
-</code>
-<strong>ivysettings-main-chain.xml</strong>
-<code type="xml">
-<ivysettings>
-  <resolvers>
-    <chain name="main" dual="true">
-      <resolver ref="shared"/>
-      <resolver ref="public"/>
-    </chain>
-  </resolvers>
-</ivysettings>
-</code>
-<strong>ivysettings-default-chain.xml</strong>
-<code type="xml">
-<ivysettings>
-  <resolvers>
-    <chain name="default" returnFirst="true">
-      <resolver ref="local"/>
-      <resolver ref="main"/>
-    </chain>
-  </resolvers>
-</ivysettings>
-</code>
-
-There you go, you should have enough clues to configure Ivy the way you want. 
Check the [[settings settings documentation]] to see if what you want to do is 
possible, and go ahead!
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/dependence.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/dependence.html b/doc/tutorial/dependence.html
deleted file mode 100644
index e76dbae..0000000
--- a/doc/tutorial/dependence.html
+++ /dev/null
@@ -1,192 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-This tutorial will show you how to use Ivy when one of your projects depends 
on another.
-
-For our example, we will have two projects, depender and dependee, where the 
depender project uses/requires the dependee project. This example will help 
illustrate two things about Ivy: 
-<ul>
-  <li>that dependencies defined by parent projects (dependee) will 
automatically be retrieved for use by child projects (depender)</li>
-  <li>that child projects can retrieve the "latest" version of the dependee 
project</li>
-</ul>
-<h1>projects used</h1>
-<h2>dependee</h2>
-The dependee project is very simple. It depends on the apache library 
commons-lang and contains only one class: <tt>standalone.Main</tt> which 
provides two services:
-<ul>
-  <li>return the version of the project</li>
-  <li>capitalize a string using 
<tt>org.apache.commons.lang.WordUtils.capitalizeFully</tt></li>
-</ul>
-Here is the content of the project:
-<ul>
-  <li>build.xml: the ant build file for the project</li>
-  <li>ivy.xml: the project ivy file</li>
-  <li>src\standalone\Main.java: the only class of the project</li>
-</ul>
-Take a look at the <b>ivy.xml</b> file:
-<code>
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="dependee"/>
-    <dependencies>
-        <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
-    </dependencies>
-</ivy-module>
-</code>
-
-The ivy file declares only one dependency, that being the apache commons-lang 
library.
-<h2>depender</h2>
-The depender project is very simple as well. It declares only one dependency 
on the latest version of the dependee project, and it contains only one class, 
<tt>depending.Main</tt>, which does 2 things:
-<ul>
-  <li>gets the version of the standalone project by calling 
<tt>standalone.Main.getVersion()</tt></li>
-  <li>transforms a string by calling 
<tt>standalone.Main.capitalizeWords(str)</tt></li>
-</ul>
-Take a look at the <tt>ivy.xml</tt> file:
-<code>
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="depender"/>
-    <dependencies>
-        <dependency name="dependee" rev="latest.integration" />
-    </dependencies>
-</ivy-module>
-</code>
-
-<h1>settings</h1>
-The Ivy settings are defined in two files located in the settings directory:
-<ul>
-  <li><tt>ivysettings.properties</tt>: a property file</li>
-  <li><tt>ivysettings.xml</tt>: the file containing the settings</li>
-</ul>
-
-Let's have a look at the <tt>ivysettings.xml</tt> file:
-<code>
-<ivysettings>
-       <properties file="${ivy.settings.dir}/ivysettings.properties"/>
-       <settings defaultResolver="libraries" />
-       <caches defaultCacheDir="${ivy.settings.dir}/ivy-cache" />
-       <resolvers>
-               <filesystem name="projects">
-                       <artifact 
pattern="${repository.dir}/[artifact]-[revision].[ext]" />
-                       <ivy 
pattern="${repository.dir}/[module]-[revision].xml" />
-               </filesystem>
-               <ibiblio name="libraries" m2compatible="true" usepoms="false" />
-       </resolvers>
-       <modules>
-               <module organisation="org.apache" name="dependee" 
resolver="projects"/>
-       </modules>
-</ivysettings>
-</code>
-The file contains four main tags: properties, settings, resolvers and modules.
-<h2>properties</h2>
-This tag loads some properties for the Ivy process, just like Ant does.
-<h2>settings</h2>
-This tag initializes some parameters for the Ivy process. In this case, the 
directory that Ivy will use to cache artifacts will be in a sub directory 
called ivy-cache of the directory containing the <tt>ivysettings.xml</tt> file 
itself. 
-The second parameter, tells Ivy to use a resolver named "libraries" as its 
default resolver. More information can be found in the [[settings settings 
reference documentation]].
-<h2>resolvers</h2>
-This tag defines the resolvers to use. Here we have two resolvers defined: 
"projects" and "libraries".
-The filesystem resolver called "projects" is able to resolve the internal 
dependencies by locating them on the local filesystem. 
-The ibiblio resolver called "libraries" is able to find dependencies on the 
maven 2 repository, but doesn't use maven poms.
-<h2>modules</h2>
-The modules tag allows you to configure which resolver should be used for 
which module. Here the setting tells Ivy to use the "projects" resolver for all 
modules having an organisation of <tt>org.apache</tt> and module name of 
<tt>dependee</tt>. This actually corresponds to only one module, but a regular 
expression could be used, or many other types of expressions (like glob 
expressions).
-
-All other modules (i.e. all modules but org.apache#dependee), will use the 
default resolver ("libraries").
-<h1>walkthrough</h1>
-<div class="step">
-<h2>step 1: preparation</h2>
-Open a DOS or shell window, and go to the <tt>src/example/dependence</tt> 
directory.
-</div>
-<div class="step">
-<h2>step 2: clean directory tree</h2>
-On the prompt type: <tt>ant</tt>
-This will clean up the entire project directory tree. You can do this each 
time you want to clean up this example.
-</div>
-<div class="step">
-<h2>step 3: publication of dependee project</h2>
-Go to <tt>dependee</tt> directory  and publish the project
-<div class="shell"><pre>
-[<tutorial/log/dependence-standalone.txt>]
-</pre></div>
-What we see here:
-<ul>
-  <li>the project depends on 1 library (1 artifact)</li>
-  <li>the library was not in the Ivy cache and so was downloaded (1 
downloaded)</li>
-  <li>the project has been released under version number 1</li>
-</ul>
-</div>
-As you can see, the call to the publish task has resulted in two main things:
-<ul>
-<li>the delivery of a resolved ivy file to <tt>build/ivy.xml</tt>.</li>
-This has been done because by default, the publish task not only publishes 
artifacts, but also its ivy file. So it has looked to the path where the ivy 
file to publish should be, using the artifactspattern: 
<tt>${build.dir}/[artifact].[ext]</tt>. For an ivy file, this resolves to 
<tt>build/ivy.xml</tt>. Because this file does not exist, it automatically 
makes a call to the deliver task which delivers a resolved ivy file to this 
destination.
-
-<li>the publication of artifact 'dependee' and its resolved ivy file to the 
repository.</li>
-Both are just copies of the files found in the current project, or more 
precisely, those in the <tt>build</tt> directory. This is because the 
artifactspattern has been set to <tt>${build.dir}/[artifact].[ext]</tt>, so the 
dependee artifact is found at <tt>build/dependee.jar</tt> and the ivy file in 
<tt>build/ivy.xml</tt>. And because we have asked the publish task to publish 
them using the "projects" resolver, these files are copied to 
<tt>repository\dependee-1.jar</tt> and to <tt>repository\dependee-1.xml</tt>, 
respecting the artifact and ivy patterns of our settings (see above).
-</ul>
-
-<div class="step">
-<h2>step 4: running the depender project</h2>
-Go to directory depender and run <tt>ant</tt>
-<div class="shell"><pre>
-[<tutorial/log/dependence-depending.txt>]
-</pre></div>
-What we see here:
-<ul>
-  <li>the project depends on 2 libraries (2 artifacts)</li>
-  <li>one of the libraries was in the cache because there was only 1 download 
(1 downloaded)</li>
-  <li>Ivy retrieved version 1 of the project "dependee". The call to 
<tt>standalone.Main.getVersion()</tt> has returned 1. If you look in the 
<tt>depender/lib</tt> directory, you should see <tt>dependee-1.jar</tt> which 
is the version 1 artifact of the project "dependee"</li>
-  <li>the call to <tt>standalone.Main.capitalizeWords(str)</tt> succeed, which 
means that the required library was in the classpath. If you look at the 
<tt>lib</tt> directory, you will see that the library 
<tt>commons-lang-2.0.jar</tt> was also retrieved. This library was declared as 
a dependency of the "dependee" project, so Ivy retrieves it (transitively) 
along with the dependee artifact.</li>
-</ul>
-</div>
-<div class="step">
-<h2>step 5: new version of dependee project</h2>
-Like we did before in step 3, publish the dependee project again. This will 
result in a new version of the project being published.
-<div class="shell"><pre>
-[<tutorial/log/dependence-standalone-2.txt>]
-</pre></div>
-Now if you look in your repository folder, you will find 2 versions of the 
dependee project.
-Let's look at it:
-<div class="shell"><pre>I:\dependee>dir ..\settings\repository /w
-
-[.]                [..]               dependee-1.jar   dependee-1.xml   
dependee-2.jar   dependee-2.xml
-
-I:\dependee></pre></div>
-</div>
-OK, now our repository contains two versions of the project <b>dependee</b>, 
so other projects can refer to either version.
-<div class="step">
-<h2>step 6: get the new version in <em>depender</em> project</h2>
-What should we expect if we run the depender project again? It should: 
-<ul>
-  <li>retrieve version 2 as the latest.integration version of the dependee 
project</li>
-  <li>display version 2 of dependee project</li>
-</ul>
-Let's try it!!
-<div class="shell"><pre>
-[<tutorial/log/dependence-depending-2.txt>]
-</pre></div>
-OK, we got what we expected as the <tt>run</tt> target shows that we are using 
version 2 of the main class of the dependee project. If we take a look at the 
resolve target results, we see that one artifact has been downloaded to the ivy 
cache. In fact, this file is the same version 2 of the dependee project that is 
in the repository, but now all future retrievals will pull it from your 
ivy-cache directory.
-</div>
-
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/dual.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/dual.html b/doc/tutorial/dual.html
deleted file mode 100644
index 33c7c11..0000000
--- a/doc/tutorial/dual.html
+++ /dev/null
@@ -1,128 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-In some cases, your module descriptions (i.e. Ivy files, maven poms) are 
located separately from the module artifacts (i.e. jars). So what can you do 
about it?
-
-Use a Dual resolver! And this tutorial will show you how.
-
-<h1>project description</h1>
-Let's have a look at the <tt>src/example/dual</tt> directory in your Ivy 
distribution.
-It contains a build file and 3 directories:
-<ul>
-<li>settings: contains the ivy settings file</li>
-<li>repository: a sample repository of ivy files</li>
-<li>project: the project making use of Ivy with dual resolver</li>
-</ul>
-
-<h2>the dual project</h2>
-The project is very simple and contains only one simple class: 
<tt>example.Hello</tt>
-It depends on two libraries: Apache commons-lang and Apache commons-httpclient.
-
-Here is the content of the project:
-<ul>
-  <li>build.xml: the ant build file for the project</li>
-  <li>ivy.xml: the ivy project file</li>
-  <li>src\example\Hello.java: the only class of the project</li>
-</ul>
-
-Let's have a look at the <tt>ivy.xml</tt> file:
-<code>
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="hello-ivy"/>
-    <dependencies>
-        <dependency org="commons-httpclient" name="commons-httpclient" 
rev="2.0.2"/>
-        <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
-    </dependencies>
-</ivy-module>
-</code>
-
-As you can see, nothing special here... Indeed, Ivy's philosophy is to keep 
ivy files independent of the way dependencies are resolved.
-
-<h2>the <b>ivy</b> settings</h2>
-The ivy settings are defined in the <tt>ivysettings.xml</tt> file located in 
the <tt>settings</tt> directory. Here is what it contains, followed by an 
explanation.
-
-<code>
-<ivysettings>
-  <settings defaultResolver="dual-example"/>
-  <resolvers>
-    <dual name="dual-example">
-      <filesystem name="ivys">
-        <ivy 
pattern="${ivy.settings.dir}/../repository/[module]-ivy-[revision].xml" />
-      </filesystem>
-      <ibiblio name="ibiblio" m2compatible="true" usepoms="false" />
-    </dual>
-  </resolvers>
-</ivysettings>
-</code>
-
-Here we configured one resolver, the default one, which is a dual resolver. 
This dual resolver has two sub resolvers: the first is what is called the "ivy" 
or "metadata" resolver of the dual resolver, and the second one is what is 
called the "artifact" resolver. It is important that the dual resolver has 
exactly two sub resolvers in this given order.
-
-The metadata resolver, here a filesystem one, is used only to find module 
descriptors, in this case Ivy files. The setting shown here tells Ivy that all 
ivy files are in the <tt>repository</tt> directory, named with the pattern: 
<tt>[module]-ivy-[revision].xml</tt>. If we check the <tt>repository</tt> 
directory, we can confirm that it contains a file named 
<tt>commons-httpclient-ivy-2.0.2.xml</tt>. This file matches the pattern, so it 
will be found by the resolver.
-
-The artifact resolver is simply an ibiblio one, configured in m2compatible 
mode to use the maven 2 repository, with <tt>usepoms="false"</tt> to make sure 
it won't use maven 2 metadata. Note that this isn't necessary, since the second 
resolver in a dual resolver (the artifact resolver) is never asked to find 
module metadata.
-
-<h1>walkthrough</h1>
-<div class="step">
-<h2>step 1 : preparation</h2>
-Open a DOS or shell window, and go to the <tt>dual</tt> directory.
-</div>
-<div class="step">
-<h2>step 2 : clean up</h2>
-On the prompt type : <tt>ant</tt><br>
-This will clean up the entire project directory tree (compiled classes and 
retrieved libs) and the Ivy cache. You can run this each time you want to clean 
up this example.
-</div>
-<div class="step">
-<h2>step 3 : run the project</h2>
-Go to the project directory. And simply run <tt>ant</tt>.
-<div class="shell"><pre>
-[<tutorial/log/dual.txt>]
-</pre></div></div>
-<br/>
-As you can see, Ivy not only downloaded commons-lang and commons-httpclient, 
but also commons-logging. Indeed, commons-logging is a dependency of 
httpclient, as we can see in the httpclient ivy file found in the 
<tt>repository</tt> directory:
-<code>
-<ivy-module version="1.0">
-    <info 
-        organisation="commons-httpclient"
-        module="commons-httpclient"
-        revision="2.0.2"
-        status="release"
-        publication="20041010174300"/>
-    <dependencies>
-        <dependency org="commons-logging" name="commons-logging" rev="1.0.4" 
conf="default"/>
-    </dependencies>
-</ivy-module>
-</code>
-<br/>
-So everything seemed to work. The ivy file was found in the 
<tt>repository</tt> directory and the artifacts have been downloaded from 
ibiblio. 
-
-This kind of setup can be useful if you don't want to rely on the maven 2 
repository for metadata, or if you want to take full advantage of Ivy files for 
some or all modules. Combining chain and dual resolvers should give you enough 
flexibility to meet almost any requirement.
-
-For full details about the dual resolver, have a look at the corresponding 
[[resolver/dual reference documentation]].
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/multiple.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/multiple.html b/doc/tutorial/multiple.html
deleted file mode 100644
index d48a250..0000000
--- a/doc/tutorial/multiple.html
+++ /dev/null
@@ -1,134 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-This tutorial is an example of how modules can be retrieved by multiple 
resolvers. Using multiple resolvers can be useful in many contexts. For example:
-<ul>
-<li>separating integration builds from releases</li>
-<li>using a public repository for third party modules and a private one for 
internal modules</li>
-<li>use a repository for storing modules which are not accurate in an 
unmanaged public repository</li>
-<li>use a local repository to expose builds made on one developer's 
station</li>
-</ul>
-
-In Ivy, the use of multiple resolvers is supported by a compound resolver 
called the chain resolver.
-
-In our example, we will simply show you how to use two resolvers, one on a 
local repository and one using the maven2 repository.
-
-<h1>project description</h1>
-<h2>the project: chained-resolvers</h2>
-The project is very simple and contains only one simple class: example.Hello.
-
-It depends on two libraries: Apache's commons-lang and a custom library named 
test (sources are included in test-1.0jar file). The test library is used by 
the project to uppercase a string, and commons-lang is used to capitalize the 
same string.
-
-Here is the content of the project:
-<ul>
-  <li>build.xml: the ant build file for the project</li>
-  <li>ivy.xml: the Ivy project file</li>
-  <li>src\example\Hello.java: the only class of the project</li>
-</ul>
-Let's have a look at the <b>ivy.xml</b> file:
-<code>
-<ivy-module version="1.0">
-    <info organisation="org.apache" module="chained-resolvers"/>
-    <dependencies>
-        <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
-        <dependency name="test" rev="1.0"/>
-    </dependencies>
-</ivy-module>
-</code>
-As we'd expect, the ivy file declares this module to be dependent on the two 
libraries it uses: 'commons-lang' and 'test'. Note that we didn't specify the 
org for the dependency 'test'. When we exclude org, Ivy assumes it is in the 
same org as the declaring module. (i.e. 'org.apache').
-
-<h2>the <b>ivy settings</b></h2>
-The settings are defined in the ivysettings.xml file located in the settings 
directory of the project. Below are its contents, followed by an explanation of 
what it's doing.
-
-<code>
-<ivysettings>
-  <settings defaultResolver="chain-example"/>
-  <resolvers>
-    <chain name="chain-example">
-      <filesystem name="libraries">
-        <artifact 
pattern="${ivy.settings.dir}/repository/[artifact]-[revision].[ext]" />
-      </filesystem>
-      <ibiblio name="ibiblio" m2compatible="true" />
-    </chain>
-  </resolvers>
-</ivysettings>
-</code>
-<h2>the <b>settings</b> tag</h2>
-This tag initializes Ivy with some parameters. Here only one parameter is set, 
the name of the resolver to use by default.
-
-<h2>the <b>resolvers</b> tag</h2>
-The resolvers section defines the list of resolvers that Ivy will use to 
locate artifacts. In our example, we have only one resolver named 
"chain-example", which is unique in that it defines a list (hence a chain) of 
resolvers.
-The resolvers in this chain are:
-<ul>
-  <li>libraries : It is a filesystem resolver, so looks at a directory 
structure to retrieve the artifacts. This one is configured to look in the 
<tt>repository</tt> sub directory of the directory that contains the 
<tt>ivysettings.xml</tt> file.</li>
-  <li>ibiblio : It looks in the ibiblio maven repository to retrieve the 
artifacts.</li>
-</ul>
-
-That's it, we have just configured a chain of resolvers!
-
-<h1>walkthrough</h1>
-<div class="step">
-<h2>step 1: preparation</h2>
-Open a DOS or shell window, and go to the "chained-resolvers" directory.
-</div>
-<div class="step">
-<h2>step 2: clean directory tree</h2>
-On the prompt type: ant<br>
-This will clean up the entire project directory tree and Ivy cache. You can do 
this each time you want to clean up this example.
-
-<div class="tip">
-In almost all examples, we provide a clean target as default target. Since 
most examples use the same Ivy cache, you will clean the whole Ivy cache each 
time you call this target. 
-
-Cleaning the Ivy cache is something you can do without fear (except 
performance): it's only a cache, so everything can be (and should be) obtained 
again from repositories. This may sound strange to those coming from maven 2 
land. But remember that in Ivy, the cache is not a local repository and the two 
are completely isolated.
-</div>
-</div>
-<div class="step">
-<h2>step 3: run the project</h2>
-Go to <tt>chained-resolvers</tt> project directory. And simply run 
<tt>ant</tt>.
-
-<div class="shell"><pre>
-[<tutorial/log/chained-resolvers.txt>]
-</pre></div></div>
-
-We can see in the log of the resolve task, that the two dependencies have been 
retrieved (2 artifacts) and copied to the Ivy cache directory (2 downloaded). 
-
-Also notice that the 'run' Ant target succeeded in using both commons-lang.jar 
coming from the ibiblio repository and test.jar coming from the local 
repository.
-
-<h1>Going further</h1>
-This very simple example helps us see how to set up two resolvers in a chain. 
The [[resolver/chain chain resolver's reference documentation]] is available 
for those who would like to know all the features offered by this resolver.
-
-Below are a few more interesting things worth knowing about chain resolvers. 
After reading them, go ahead and try tweaking this example using your new 
wealth of knowledge!
-<ul>
-<li>a chain is not limited to two nested resolvers, you can use as many as you 
want</li>
-<li>by setting <tt>returnFirst="true"</tt>, you can have a chain which stops 
as soon as it has found a result for a given module</li>
-<li>by setting <tt>dual="true"</tt>, the full chain will be used both for 
module descriptors and artifacts, while setting <tt>dual="false"</tt>, the 
resolver in the chain which found the module descriptor (if any) is also used 
for artifacts</li>
-</ul>
-
-       </textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/multiproject.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/multiproject.html b/doc/tutorial/multiproject.html
deleted file mode 100644
index a7f3a10..0000000
--- a/doc/tutorial/multiproject.html
+++ /dev/null
@@ -1,216 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-In the previous tutorial, you saw how to deal with dependencies between two 
simple projects.
-
-This tutorial will guide you through the use of Ivy in a more complete 
environment. All of the code for this tutorial is available in the 
<tt>src/example/multi-project</tt> directory of the Ivy distribution.
-
-<h1>Context</h1>
-Here is a 10000ft overview of the projects involved in this tutorial:
-<ul>
-<li>version</li> helps to identify module by a version
-<li>list</li> gives a list of files in a directory (recursively)
-<li>size</li> gives the total size of all files in a directory, or of a 
collection of files
-<li>find</li> find files in a given dir or among a list of files which match a 
given name
-<li>sizewhere</li> gives the total size of files matching a name in a directory
-<li>console</li> give access to all other modules features through a simple 
console app
-</ul>
-For sure this is not aimed to demonstrate how to develop a complex app or give 
indication of advanced algorithm :-)
-
-But this gives a simple understanding of how Ant+Ivy can be used to develop an 
application divided in multiple modules.
-
-Now, here is how these modules relate to each other:
-<center><a href="../samples/projects-dependencies-graph.jpg"><img 
src="../samples/projects-dependencies-graph-small.jpg" alt="dependencies 
graph"/><br/><i>click to enlarge</i></a></center>
-
-Modules in yellow are the modules described in this tutorial, and modules in 
blue are external dependencies (we will see how to generate this graph later in 
this tutorial).
-
-As you can see, we have here a pretty interesting set of modules with 
dependencies between each other, each depending on the latest version of the 
others.
-
-<h1>The example files</h1>
-The sources for this tutorial can be found in 
<tt>src/example/multi-project</tt> in the Ivy distribution. In this directory, 
you will find the following files:
-<ul>
-<li>[[gitfile:src/example/multi-project/build.xml build.xml]]</li>This is a 
root build file which can be used to call targets on all modules, in the order 
of their dependencies (ensuring that a module is always built before any module 
depending on it, for instance)
-<li>common
-<ul>
-<li>[[gitfile:src/example/multi-project/common/common.xml common.xml]]</li> 
the common build file imported by all build.xml files for each project. This 
build defines the targets which can be used in all projects.
-<li>[[gitfile:src/example/multi-project/common/build.properties 
build.properties]]</li>some properties common to all projects
-</ul>
-</li>
-<li>projects</li>
-contains a directory per module, with each containing:
-<ul>
-<li>ivy.xml</li>Ivy file of the module, describing its dependencies upon other 
modules and/or external modules.
-Example:
-<code type="xml">
-<ivy-module version="1.0">
-    <info 
-        organisation="org.apache.ivy.example"
-        module="find"
-        status="integration"/>
-    <configurations>
-      <conf name="core"/>
-      <conf name="standalone" extends="core"/>
-    </configurations>
-    <publications>
-      <artifact name="find" type="jar" conf="core" />
-    </publications>
-    <dependencies>
-      <dependency name="version" rev="latest.integration" conf="core->default" 
/>
-      <dependency name="list" rev="latest.integration" conf="core" />
-      <dependency org="commons-collections" name="commons-collections" 
rev="3.1" conf="core->default" />
-      <dependency org="commons-cli" name="commons-cli" rev="1.0" 
conf="standalone->default" />
-    </dependencies>
-</ivy-module>
-</code>
-<li>build.xml</li>The build file of the project, which consists mainly of an 
import of the common build file and of a module specific properties file:
-<code type="xml">
-<project name="find" default="compile">
-       <property file="build.properties"/>
-       
-       <import file="${common.dir}/common.xml"/>
-</project>
-</code>
-<li>build.properties</li>Module specific properties + properties to find the 
common build file
-<code>
-projects.dir = ${basedir}/..
-wkspace.dir = ${projects.dir}/..
-common.dir = ${wkspace.dir}/common
-</code>
-<li>src</li> the source directory with all java sources
-</ul>
-</ul>
-
-Note that this example doesn't demonstrate many good practices for software 
development in general, in particular you won't find any unit test in these 
samples, even if we think unit testing is very important. But this isn't the 
aim of this tutorial.
-
-Now that you are a bit more familiar with the structure, let's have a look at 
the most important part of this example: the common build file. Indeed, as you 
have seen, all the module's build files only import the common build file, and 
define their dependencies in their ivy files (which you should begin to be 
familiar with).
-
-So, here are some aspects of this common build file:
-<h2>ivy settings</h2>
-<code type="xml">
-<!-- setup ivy default configuration with some custom info -->
-<property name="ivy.local.default.root" value="${repository.dir}/local"/>
-<property name="ivy.shared.default.root" value="${repository.dir}/shared"/>
-
-<!-- here is how we would have configured ivy if we had our own ivysettings 
file
-<ivy:settings file="${common.dir}/ivysettings.xml" id="ivy.instance" />
--->
-</code>
-
-This declaration configures Ivy by only setting two properties: the location 
for the local repository and the location for the shared repository. It's the 
only settings done here, since Ivy is configured by default to work in a team 
environment (see [[tutorial/defaultconf default settings tutorial]] for details 
about this). For sure in a real environment, the shared repository location 
would rather be in a team shared directory (or in a more complex repository, 
again see the default settings tutorial to see how to use something really 
different).
-Commented out you can see how the settings would have been done if the default 
setting wasn't OK for our purpose.
-
-<h2>resolve dependencies</h2>
-<code type="xml">
-<target name="resolve" depends="clean-lib, load-ivy" description="--> resolve 
and retrieve dependencies with ivy">
-    <mkdir dir="${lib.dir}"/> <!-- not usually necessary, ivy creates the 
directory IF there are dependencies -->
-    
-    <!-- the call to resolve is not mandatory, retrieve makes an implicit call 
if we don't -->
-    <ivy:resolve file="${ivy.file}"/>
-    <ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" />
-</target>
-</code>
-You should begin to be familiar with using Ivy this way. We call 
<i>resolve</i> explicitly to use the ivy file configured (the default would 
have been fine), and then call <i>retrieve</i> to copy resolved dependencies 
artifacts from the cache to a local lib directory. The pattern is also used to 
name the artifacts in the lib dir with their name and extension only (without 
revision), this is easier to use with an IDE, as the IDE configuration won't 
change when the artifacts version change.
-
-<h2>ivy-new-version</h2>
-<code type="xml">
-<target name="ivy-new-version" depends="load-ivy" unless="ivy.new.revision">
-    <!-- default module version prefix value -->
-    <property name="module.version.prefix" 
value="${module.version.target}-dev-b" />
-    
-    <!-- asks Ivy for an available version number -->
-    <ivy:info file="${ivy.file}" />
-    <ivy:buildnumber 
-        organisation="${ivy.organisation}" module="${ivy.module}" 
-        revision="${module.version.prefix}" defaultBuildNumber="1" revSep=""/>
-</target>
-</code>
-This target is used to ask Ivy to find a new version for a module. To get 
details about the module we are dealing with, we pull information out of the 
ivy file by using the ivy:info task. Then the [[ant:buildnumber]] task is used 
to get a new revision, based on a prefix we set with a property, by default it 
will be 1.0-dev-b (have a look at the default value for 
<tt>module.version.target</tt> in the <tt>common/build.properties</tt> file). 
Each module built by this common build file could easily override this by 
either setting a different <tt>module.version.target</tt> in its module 
specific <tt>build.properties</tt>, or even overriding 
<tt>module.version.prefix</tt>. To get the new revision, Ivy scans the 
repository to find the latest available version with the given prefix, and then 
increments this version by 1.
-
-<h2>publish</h2>
-<code type="xml">
-<target name="publish" depends="clean-build, jar" description="--> publish 
this project in the ivy repository">
-    <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" 
-                       resolver="shared"
-                       pubrevision="${version}" 
-                       status="release"
-    />
-    <echo message="project ${ant.project.name} released with version 
${version}" />
-</target>
-</code>
-This target publishes the module to the shared repository, with the revision 
found in the version property, which is set by other targets (based on 
ivy-new-version we have seen above). It can be used when a module reaches a 
specific milestone, or whenever you want the team to benefit from a new version 
of the module.
-<h2>publish-local</h2>
-<code type="xml">
-<target name="publish-local" depends="local-version, jar" description="--> 
publish this project in the local ivy repository">
-    <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" 
-                    resolver="local"
-                    pubrevision="${version}"
-                    pubdate="${now}"
-                    status="integration"
-                    forcedeliver="true"
-    />
-    <echo message="project ${ant.project.name} published locally with version 
${version}" />
-</target>
-</code>
-This is very similar to the publish task, except that this publishes the 
revision to the local repository, which is used only in your environment and 
doesn't disturb the team. When you change something in a module and want to 
benefit from the change in another one, you can simply call 
<tt>publish-local</tt> in this module, and then your next build of the other 
module will automatically get this local version.
-<h2>clean-local</h2>
-<code type="xml">
-<target name="clean-local" description="--> cleans the local repository for 
the current module">
-   <delete dir="${ivy.local.default.root}/${ant.project.name}"/>
-</target>
-</code>
-This target is used when you don't want to use your local version of a module 
anymore. For example, when you release a new version to the whole team, or 
discard your local changes and want to take advantage of a new version from the 
team.
-<h2>report</h2>
-<code type="xml">
-<target name="report" depends="resolve" description="--> generates a report of 
dependencies">
-    <ivy:report todir="${build.dir}"/>
-</target>
-</code>
-Generates both an html report and a graphml report.
-
-For example, to generate a graph like the one shown at the beginning of this 
tutorial, you just have to follow the instructions given [[yed here]] with the 
graphml file you will find in <code>projects/console/build/</code> after having 
called report in the console project, and that's it, you have a clear overview 
of all your app dependencies!
-
-<h1>Playing with the projects</h1>
-You can play with this tutorial by using regular Ant commands. Begin in the 
base directory of the tutorial (src/example/multi-project), and run ant -p:
-<div class="shell"><pre>
-[<tutorial/log/multi-project-general-antp.txt>]
-</pre></div>
-
-This gives you an idea of what you can do here. To make sure you have at least 
one version of all your modules published in your repository (required to build 
modules having dependencies on the others), you can run <tt>ant 
publish-all</tt> (example log <a 
href="log/multi-project-general-publishall.txt">here</a>).
-
-You will see that Ivy calls the publish target on all the modules, following 
the order of the dependencies, so that a dependee is always built and published 
before its depender. Feel free to make changes in the source code of a module 
(changing a method name for instance) and in the module using the method, then 
call publish-all to see how the change in the dependee is compiled first, 
published, and then available to the depender which can compile successfully.
-
-Then you can go in one of the example project directories (like projects/find 
for instance), and run <tt>ant -p</tt>:
-<div class="shell"><pre>
-[<tutorial/log/multi-project-find-antp.txt>]
-</pre></div>
-
-You can see the targets available, thanks to the import of the 
<tt>common.xml</tt> build file. Play with the project by calling resolve, and 
publish, and see what happens when you do the same in other projects. An 
interesting thing to do for instance, is to change the dependencies of a 
project. If the module version now depends on a new commons library, you will 
see that all other projects depending on that version will get this library as 
part of their transitive dependencies once the new revision of the version 
project is published. Very easy! And if a project introduces a change with 
which the depender isn't compatible with yet, you can easily change the 
dependency in the depender to move from <tt>latest.integration</tt> to a fixed 
version with which the depender is compatible (probably the latest before the 
change). Keeping your modules under control is now very easy!
-
-By now, you should be pretty familiar with multi-project development with Ivy. 
We hope you will appreciate its power and flexibility! And these tutorials are 
only the beginning of your journey with Ivy, browse the [[reference reference 
documentation]] to learn more about the features, subscribe to the 
[[mailing-lists mailing lists]] to share your experience and ask questions with 
the community, browse the source code, open jira issues, submit patches, join 
in and help make Ivy the best of dependency management tools!</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/0c769150/doc/tutorial/start.html
----------------------------------------------------------------------
diff --git a/doc/tutorial/start.html b/doc/tutorial/start.html
deleted file mode 100644
index d9056bb..0000000
--- a/doc/tutorial/start.html
+++ /dev/null
@@ -1,104 +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>
-</head>
-<body>
-       <textarea id="xooki-source">
-In this tutorial, you will see one of the simplest ways to use Ivy. With no 
specific settings, Ivy uses the maven 2 repository to resolve the dependencies 
you declare in an Ivy file. Let's have a look at the content of the files 
involved. 
-
-<em>You'll find this tutorial's sources in the ivy distribution in the 
src/example/hello-ivy directory.</em>
-
-<h1>The ivy.xml file</h1>
-This file is used to describe the dependencies of the project on other 
libraries.
-Here is the sample: 
-<code type="xml">
-<ivy-module version="2.0">
-    <info organisation="org.apache" module="hello-ivy"/>
-    <dependencies>
-        <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
-        <dependency org="commons-cli" name="commons-cli" rev="1.0"/>
-    </dependencies>
-</ivy-module>
-</code>
-
-The format of this file should pretty easy to understand, but let's give some 
details about what is declared here. First, the root element ivy-module, with 
the version attribute used to tell Ivy which version of Ivy this file uses. 
-
-Then there is an info tag, which is used to give information about the module 
for which we are defining dependencies. Here we define only the organization 
and module name. You are free to choose whatever you want for them, but we 
recommend avoiding spaces for both.
-
-Finally, the dependencies section lets you define dependencies. Here this 
module depends on two libraries: commons-lang and commons-cli. As you can see, 
we use the <tt>org</tt> and <tt>name</tt> attributes to define the organization 
and module name of the dependencies we need. The <tt>rev</tt> attribute is used 
to specify the version of the module you depend on. 
-
-To know what to put in these attributes, you need to know the exact 
information for the libraries you depend on. Ivy uses the maven 2 repository by 
default, so we recommend you use <a 
href="http://mvnrepository.com";>mvnrepository.com</a> to look for the module 
you want. Once you find it, you will have the details on how to declare the 
dependency in a maven POM. For instance:
-<code>
-<dependency>
-    <groupId>commons-lang</groupId>
-    <artifactId>commons-lang</artifactId>
-    <version>2.0</version>
-</dependency>
-</code>
-To convert this into an Ivy dependency declaration, all you have to do is use 
the groupId as organization, the artifactId as module name, and the version as 
revision. That's what we did for the dependencies in this tutorial, that is 
commons-lang and commons-cli. Note that having commons-lang and commons-cli as 
organization is not the best example of what the organization should be. It 
would be better to use org.apache, org.apache.commons or 
org.apache.commons.lang. However, this is how these modules are identified in 
the maven 2 repository, so the simplest way to get them is to use the details 
as is (you will see in [[tutorial/build-repository]] that you can use 
namespaces to redefine these names if you want something cleaner).
-
-If you want more details on what you can do in Ivy files, you can have a look 
at the [[ivyfile Ivy files reference documentation]].
-<h1>The build.xml file</h1>
-The corresponding build file contains a set of targets, allowing you to 
resolve dependencies declared in the Ivy file, to compile and run the sample 
code, produce a report of dependency resolution, and clean the cache or the 
project.
-You can use the standard "ant -p" to get the list of available targets. Feel 
free to have a look at the whole file, but here is the part relevant to 
dependency resolution:
-<code type="xml">
-<project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run">
-    
-    ...
-    
-    <!-- ================================= 
-          target: resolve              
-         ================================= -->
-    <target name="resolve" description="--> retrieve dependencies with ivy">
-        <ivy:retrieve />
-    </target>
-</project>
-</code>
-As you can see, it's very easy to call Ivy to resolve and retrieve 
dependencies: all you need if Ivy is properly [[install installed]] is to 
define an XML namespace in your Ant file 
(xmlns:ivy="antlib:org.apache.ivy.ant"). Then all the [[ant Ivy ant tasks]] 
will be available in this namespace.
-
-Here we use only one task: the [[use/retrieve]] task. With no attributes, it 
will use default settings and look for a file named <tt>ivy.xml</tt> for the 
dependency definitions. That's exactly what we want, so we need nothing more 
than that.
-
-Note that in this case we define a <tt>resolve</tt> target and call the 
<tt>[[use/retrieve]]</tt> task. This may sound confusing, actually the retrieve 
task performs a [[use/resolve]] (which resolves dependencies and downloads them 
to a cache) followed by a retrieve (a copy of those file to a local project 
directory). Check the [[principle]] page for details about that.
-<h1>Running the project</h1>
-OK, now that we have seen the files involved, let's run the sample to see what 
happens. Open a shell (or command line) window, and enter the 
<tt>hello-ivy</tt> example directory.
-Then, at the command prompt, run <tt>ant</tt>:
-<div class="shell"><pre>
-[<tutorial/log/hello-ivy-1.txt>]
-</pre></div>
-<h1>What happened ?</h1>
-Without any settings, Ivy retrieves files from the maven 2 repository. That's 
what happened here. 
-The resolve task has found the commons-lang and commons-cli modules in the 
maven 2 repository, identified that commons-cli depends on commons-logging and 
so resolved it as a transitive dependency. Then Ivy has downloaded all 
corresponding artifacts in its cache (by default in your user home, in a 
.ivy2/cache directory). Finally, the retrieve task copies the resolved jars 
from the ivy cache to the default library directory of the project: the lib dir 
(you can change this easily by setting the pattern attribute on the 
[[use/retrieve]] task).
-
-You might say that the task took a long time just to write out a "Hello Ivy!" 
message. But remember that a lot of time was spent downloading the required 
files from the web. Let's try to run it again:
-<div class="shell"><pre>
-[<tutorial/log/hello-ivy-2.txt>]
-</pre></div>
-Great! The cache was used, so no download was needed and the build was 
instantaneous.
-
-And now, if you want to generate a report detailing all the dependencies of 
your module, you can call the report target, and check the generated file in 
the build directory. You should obtain something looking like <a 
href="../samples/apache-hello-ivy-default.html">this</a>.
-
-As you can see, using Ivy to resolve dependencies stored in the maven 2 
repository is extremely easy. Now you can go on with the next tutorials to 
learn more about [[tutorial/conf how to use module configurations]] which is a 
very powerful Ivy specific feature. Other tutorials are also available where 
you will learn how to use Ivy settings to leverage a possibly complex 
enterprise repository. It may also be a good time to start reading the 
[[reference reference documentation]], and especially the introduction material 
which gives a good overview of Ivy. The [[bestpractices best practices]] page 
is also a must read to start thinking about how to use Ant+Ivy to build a clean 
and robust build system.</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>

Reply via email to