incubator-ivy-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From xav...@apache.org
Subject svn commit: r536488 [17/19] - in /incubator/ivy/core/trunk: ./ doc/ doc/doc/ doc/doc/configuration/ doc/doc/configuration/macrodef/ doc/doc/configuration/namespace/ doc/doc/ivyfile/ doc/doc/releasenotes/ doc/doc/resolver/ doc/doc/tutorial/ doc/doc/tuto...
Date Wed, 09 May 2007 10:58:16 GMT
Propchange: incubator/ivy/core/trunk/doc/doc/use/repreport.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/doc/use/resolve.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/use/resolve.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/use/resolve.html (original)
+++ incubator/ivy/core/trunk/doc/doc/use/resolve.html Wed May  9 03:58:10 2007
@@ -1,139 +1,139 @@
-<!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">
-The resolve task actually resolve dependencies described in an <a href="../../doc/ivyfile.html">ivy file</a>, and put the resolved dependencies in the ivy cache.
-If configure has not been called before resolve is called, a default configuration will be used (equivalent to call configure with no attributes).
-
-After the call to this task, four properties are set in ant:
-<ul>
-<li>ivy.organisation</li>
-set to the organisation name found in the ivyfile which was used for resolve
-<li>ivy.module</li>
-set to the module name found in the ivyfile which was used for resolve
-<li>ivy.revision</li>
-set to the revision name found in the ivyfile which was used for resolve, or a generated revision name if no revision was specified in the file
-<li>ivy.resolved.configurations</li>
-set to the comma separated list of configurations resolved
-</ul>
-<b>Since 1.2:</b>
-An additional property is set to true if the resolved dependencies are changes since the last resolve, and to false otherwise: <code>ivy.deps.changed</code>
-
-When ivy has finished the resolve task, it outputs a summary of what has been resolved. This summary looks like this:
-<pre>
----------------------------------------------------------------------
-|                  |            modules            ||   artifacts   |
-|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
----------------------------------------------------------------------
-|      default     |   4   |   0   |   0   |   0   ||   4   |   0   |
----------------------------------------------------------------------
-</pre>
-This table gives some statistics about the dependency resolution. Each line correspond to a configuration resolved. Then the table is divided in two parts:
-<ul>
-<li>modules</li>
-<ul>
-<li>number</li>
-This is the total number of dependency modules resolved in this configuration, including transitive ones
-<li>search</li>
-This is the number of dependency modules that required a repository access. The repository access is needed if the module is not yet in cache, or if a latest version is required, or in some other cases (depending on checkModified, for instance)
-<li>downlded</li>
-This is the number of dependency ivy files downloaded from the repository. This number can be less than the total number of modules even with a clean cache, if no ivy file is provided for some dependencies.
-<li>evicted</li>
-This is the number of dependency module evicted by conflict managers.
-</ul>
-<li>artifacts</li>
-<ul>
-<li>number</li>
-This is the total number of artifacts resolved in the given configuration.
-<li>dwnlded</li>
-This is the number of artifacts actually downloaded from the repository.
-</ul>
-</ul>
-
-<span class="since">since 1.4</span> A new inline mode allow to call a resolve without an ivy file, by setting directly the module which should be resolved from the repository. It is particularly useful to install released software, like an ant task for example. When inline is set to true, the organisation module and revision attributes are used to specify which module should be resolved from the repository.
-
-<i>Note for developers:
-After the call to this task, a reference to the module descriptor resolved is put in the ant project under the id <code>"ivy.resolved.descriptor"</code>.</i>
-
-<table class="ant">
-<thead>
-    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
-</thead>
-<tbody>
-    <tr><td>file</td><td>path to the ivy file to use for resolution</td>
-        <td>No. Defaults to ${ivy.dep.file} or nothing in inline mode</td></tr>
-    <tr><td>conf</td><td>a comma separated list of the configurations to resolve</td><td>No. Defaults to ${ivy.configurations}</td></tr>
-    <tr><td>useOrigin</td><td>true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise <span class="since">since 1.4</span>. 
-To know if an artifact is local ivy asks to the resolver. Only filesystem resolver is considered local by default, but this can be disabled if you want to force the copy on one filesystem resolver and use the original location on another. Note that it is safe to use useOrigin even if you some no local resolvers, Ivy will behave as usual in this case. Note also that this only applies to artifacts, not to ivy files, which are still copied in the cache.</td><td>No. defaults to false</td></tr>
-    <tr><td>inline</td><td>true to use inline mode, false to resolve an ivy file <span class="since">since 1.4</span></td><td>No. defaults to false</td></tr>
-    <tr><td>organisation</td><td>the organisation of the module to resolve in inline mode <span class="since">since 1.4</span></td><td>Yes in inline mode, no otherwise.</td></tr>
-    <tr><td>module</td><td>the name of the module to resolve in inline mode <span class="since">since 1.4</span></td><td>Yes in inline mode, no otherwise.</td></tr>
-    <tr><td>revision</td><td>the revision constraint to apply to the module to resolve in inline mode <span class="since">since 1.4</span></td><td>No. Defaults to "latest.integration" in inline mode, nothing in standard mode.</td></tr>
-    <tr><td>type</td><td>comma separated list of accepted artifact types (<span class="since">since 1.2</span>)</td><td>No. defaults to ${ivy.resolve.default.type.filter}</td></tr>
-    <tr><td>haltonfailure</td><td>true to halt the build on ivy failure, false to continue</td><td>No. Defaults to true</td></tr>
-    <tr><td>failureproperty</td><td>the name of the property to set if the resolve failed <span class="since">since 1.4</span></td><td>No. No property is set by default.</td></tr>
-    <tr><td>transitive</td><td>true to resolve dependencies transitively, false otherwise <span class="since">since 1.4</span></td><td>No. Defaults to true</td></tr>
-    <tr><td>showprogress</td><td>true to show dots while downloading, false otherwise</td><td>No. Defaults to true</td></tr>
-    <tr><td>validate</td><td>true to force ivy files validation against ivy.xsd, false to force no validation</td><td>No. Defaults to default ivy value (as configured in configuration file)</td></tr>
-</tbody>
-</table>
-<h1>Examples</h1>
-<code type="xml">
-<ivy:resolve file="path/to/ivy.xml"/>
-</code>
-Resolve all dependencies declared in path/to/ivy.xml file.
-
-<hr/>
-
-<code type="xml">
-<ivy:resolve file="path/to/ivy.xml" transitive="false" />
-</code>
-Same as above, but with transitive dependencies disabled.
-
-<hr/>
-
-<code type="xml">
-<ivy:resolve file="path/to/ivy.xml" conf="default, test"/>
-</code>
-Resolve the dependencies declared in the configuration default and test of the path/to/ivy.xml file.
-
-<hr/>
-
-<code type="xml">
-<ivy:resolve file="path/to/ivy.xml" type="jar"/>
-</code>
-Resolve all dependencies declared in path/to/ivy.xml file, but download only jar artifacts.
-
-<hr/>
-<code type="xml">
-<ivy:resolve organisation="apache" module="commons-lang" revision="2+" inline="true" />
-</code>
-Resolve the commons-lang module revision 2+ from the repository, with its dependencies.
-
-	</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+<!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">
+The resolve task actually resolve dependencies described in an <a href="../../doc/ivyfile.html">ivy file</a>, and put the resolved dependencies in the ivy cache.
+If configure has not been called before resolve is called, a default configuration will be used (equivalent to call configure with no attributes).
+
+After the call to this task, four properties are set in ant:
+<ul>
+<li>ivy.organisation</li>
+set to the organisation name found in the ivyfile which was used for resolve
+<li>ivy.module</li>
+set to the module name found in the ivyfile which was used for resolve
+<li>ivy.revision</li>
+set to the revision name found in the ivyfile which was used for resolve, or a generated revision name if no revision was specified in the file
+<li>ivy.resolved.configurations</li>
+set to the comma separated list of configurations resolved
+</ul>
+<b>Since 1.2:</b>
+An additional property is set to true if the resolved dependencies are changes since the last resolve, and to false otherwise: <code>ivy.deps.changed</code>
+
+When ivy has finished the resolve task, it outputs a summary of what has been resolved. This summary looks like this:
+<pre>
+---------------------------------------------------------------------
+|                  |            modules            ||   artifacts   |
+|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
+---------------------------------------------------------------------
+|      default     |   4   |   0   |   0   |   0   ||   4   |   0   |
+---------------------------------------------------------------------
+</pre>
+This table gives some statistics about the dependency resolution. Each line correspond to a configuration resolved. Then the table is divided in two parts:
+<ul>
+<li>modules</li>
+<ul>
+<li>number</li>
+This is the total number of dependency modules resolved in this configuration, including transitive ones
+<li>search</li>
+This is the number of dependency modules that required a repository access. The repository access is needed if the module is not yet in cache, or if a latest version is required, or in some other cases (depending on checkModified, for instance)
+<li>downlded</li>
+This is the number of dependency ivy files downloaded from the repository. This number can be less than the total number of modules even with a clean cache, if no ivy file is provided for some dependencies.
+<li>evicted</li>
+This is the number of dependency module evicted by conflict managers.
+</ul>
+<li>artifacts</li>
+<ul>
+<li>number</li>
+This is the total number of artifacts resolved in the given configuration.
+<li>dwnlded</li>
+This is the number of artifacts actually downloaded from the repository.
+</ul>
+</ul>
+
+<span class="since">since 1.4</span> A new inline mode allow to call a resolve without an ivy file, by setting directly the module which should be resolved from the repository. It is particularly useful to install released software, like an ant task for example. When inline is set to true, the organisation module and revision attributes are used to specify which module should be resolved from the repository.
+
+<i>Note for developers:
+After the call to this task, a reference to the module descriptor resolved is put in the ant project under the id <code>"ivy.resolved.descriptor"</code>.</i>
+
+<table class="ant">
+<thead>
+    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>file</td><td>path to the ivy file to use for resolution</td>
+        <td>No. Defaults to ${ivy.dep.file} or nothing in inline mode</td></tr>
+    <tr><td>conf</td><td>a comma separated list of the configurations to resolve</td><td>No. Defaults to ${ivy.configurations}</td></tr>
+    <tr><td>useOrigin</td><td>true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise <span class="since">since 1.4</span>. 
+To know if an artifact is local ivy asks to the resolver. Only filesystem resolver is considered local by default, but this can be disabled if you want to force the copy on one filesystem resolver and use the original location on another. Note that it is safe to use useOrigin even if you some no local resolvers, Ivy will behave as usual in this case. Note also that this only applies to artifacts, not to ivy files, which are still copied in the cache.</td><td>No. defaults to false</td></tr>
+    <tr><td>inline</td><td>true to use inline mode, false to resolve an ivy file <span class="since">since 1.4</span></td><td>No. defaults to false</td></tr>
+    <tr><td>organisation</td><td>the organisation of the module to resolve in inline mode <span class="since">since 1.4</span></td><td>Yes in inline mode, no otherwise.</td></tr>
+    <tr><td>module</td><td>the name of the module to resolve in inline mode <span class="since">since 1.4</span></td><td>Yes in inline mode, no otherwise.</td></tr>
+    <tr><td>revision</td><td>the revision constraint to apply to the module to resolve in inline mode <span class="since">since 1.4</span></td><td>No. Defaults to "latest.integration" in inline mode, nothing in standard mode.</td></tr>
+    <tr><td>type</td><td>comma separated list of accepted artifact types (<span class="since">since 1.2</span>)</td><td>No. defaults to ${ivy.resolve.default.type.filter}</td></tr>
+    <tr><td>haltonfailure</td><td>true to halt the build on ivy failure, false to continue</td><td>No. Defaults to true</td></tr>
+    <tr><td>failureproperty</td><td>the name of the property to set if the resolve failed <span class="since">since 1.4</span></td><td>No. No property is set by default.</td></tr>
+    <tr><td>transitive</td><td>true to resolve dependencies transitively, false otherwise <span class="since">since 1.4</span></td><td>No. Defaults to true</td></tr>
+    <tr><td>showprogress</td><td>true to show dots while downloading, false otherwise</td><td>No. Defaults to true</td></tr>
+    <tr><td>validate</td><td>true to force ivy files validation against ivy.xsd, false to force no validation</td><td>No. Defaults to default ivy value (as configured in configuration file)</td></tr>
+</tbody>
+</table>
+<h1>Examples</h1>
+<code type="xml">
+<ivy:resolve file="path/to/ivy.xml"/>
+</code>
+Resolve all dependencies declared in path/to/ivy.xml file.
+
+<hr/>
+
+<code type="xml">
+<ivy:resolve file="path/to/ivy.xml" transitive="false" />
+</code>
+Same as above, but with transitive dependencies disabled.
+
+<hr/>
+
+<code type="xml">
+<ivy:resolve file="path/to/ivy.xml" conf="default, test"/>
+</code>
+Resolve the dependencies declared in the configuration default and test of the path/to/ivy.xml file.
+
+<hr/>
+
+<code type="xml">
+<ivy:resolve file="path/to/ivy.xml" type="jar"/>
+</code>
+Resolve all dependencies declared in path/to/ivy.xml file, but download only jar artifacts.
+
+<hr/>
+<code type="xml">
+<ivy:resolve organisation="apache" module="commons-lang" revision="2+" inline="true" />
+</code>
+Resolve the commons-lang module revision 2+ from the repository, with its dependencies.
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/doc/use/resolve.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/doc/use/retrieve.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/use/retrieve.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/use/retrieve.html (original)
+++ incubator/ivy/core/trunk/doc/doc/use/retrieve.html Wed May  9 03:58:10 2007
@@ -1,137 +1,137 @@
-<!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">
-The retrieve task copies resolved dependencies anywhere you want in your file system.
-
-This is a [[ant:postresolvetask post resolve task]], with all the behaviour and attributes common to all post resolve tasks.
-
-<span class="since">since 1.4</span> This task can even be used to synchronize the destination directory with what should actually be in according to the dependency resolution. This means that by setting sync="true", Ivy will not only copy the necessary files, but it will also remove the files which do not need to be there.
-
-The synchronisation actually consists in deleting all filles and directories in the root destination directory which are not required by the retrieve.
-
-The root destination directory is the the directory denoted by the first level up the first token in the destination pattern.
-Example:
-pattern: lib/[conf]/[artifact].[ext]
-root: lib
-
-<span class="since">since 1.4</span> The behaviour is like this when 'useOrigin=true':
-<ul>
-<li>if the artifact is not local, the location from within the cache is used</li>
-<li>if the artifact is a local artifact, it's original location is used</li>
-</ul>
-Note that if resolve has been called separately, the copy to the cache may have occur normally if useOrigin was not set when calling [[ant:resolve]]. If resolve has not been called, it will be called automatically with useOrigin set to the value specified on this task.
-
-<table class="ant">
-<thead>
-    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
-</thead>
-<tbody>
-    <tr><td>pattern</td><td>the pattern to use to copy the dependencies</td>
-        <td>No. Defaults to ${ivy.retrieve.pattern}</td></tr>
-    <tr><td>ivypattern</td><td>the pattern to use to copy the ivy files of dependencies <span class="since">since 1.3</span></td>
-        <td>No. Dependencies ivy files are not retrieved by default.</td></tr>
-    <tr><td>conf</td><td>a comma separated list of the configurations to retrieve</td>
-        <td>No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called</td></tr>
-    <tr><td>sync</td><td>true to synchronize the destination, false to just make a copy <span class="since">since 1.4</span></td>
-        <td>No. Defaults to false</td></tr>
-    <tr><td>type</td><td>comma separated list of accepted artifact types <span class="since">since 1.4</span></td>
-        <td>No. All artifact types are accepted by default.</td></tr>
-    <tr><td>useOrigin</td><td>true to copy artifacts from their original location for local artifacts, false to use only cache locations <span class="since">since 1.4</span></td>
-        <td>No. Defaults to false</td></tr>
-</tbody>
-</table>
-<h1>Examples</h1>
-<code type="xml">
-<ivy:retrieve />
-</code>
-Retrieves dependencies using default parameters. This usually retrieves all the dependencies of the last resolve call to a lib directory.
-
-<hr/>
-<code type="xml">
-<ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]"/>
-</code>
-Retrieves all dependencies of the last resolve call to a lib directory, dependencies being separated in directories named by configuration, each conf directory containing corresponding artifacts without the revision.
-For instance, if the ivy file declares two configurations default and test, the resulting lib dir could look like this:
-<code>
-lib
-  default
-    commons-lang.jar
-    commons-logging.jar
-  test
-    junit.jar
-</code>
-Note that if a dependency is required in the two configurations, it will be copied in the two directories. The download of the dependency is however only made once at resolve time.
-
-<hr/>
-<code type="xml">
-<ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]" sync="true" />
-</code>
-Same as before, but with synchronisation enabled.
-
-For instance, if the ivy file declares two configurations default and test, the resulting lib dir could look like this:
-<code>
-lib
-  default
-    commons-lang.jar
-    commons-logging.jar
-  test
-    junit.jar
-</code>
-And now suppose commons-logging is no longer part of the dependencies of the default configuration, then a new call to retrieve will result in:
-<code>
-lib
-  default
-    commons-lang.jar
-  test
-    junit.jar
-</code>
-With no synchronisation, commons-logging would not have been removed by the call.
-
-<hr/>
-<code type="xml">
-<ivy:retrieve pattern="${lib.dir}/[type]/[artifact]-[revision].[ext]" conf="runtime"/>
-</code>
-Retrieves only the dependencies of the <code>runtime</code> configuration in directories named by artifact type. The resulting lib dir could look like this:
-<code>
-lib
-  jar
-    commons-lang-1.0.jar
-    looks-1.1.jar
-  source
-    looks-1.1.zip
-</code>
-
-
-<hr/>
-<code type="xml">
-<ivy:retrieve organisation="foo" module="bar" inline="true" pattern="${my.install.dir}/[artifact].[ext]"/>
-</code>
-Resolves and retrieve the latest version of the module bar and its dependencies in the directory pointed by ${my.install.dir}.
-	</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+<!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">
+The retrieve task copies resolved dependencies anywhere you want in your file system.
+
+This is a [[ant:postresolvetask post resolve task]], with all the behaviour and attributes common to all post resolve tasks.
+
+<span class="since">since 1.4</span> This task can even be used to synchronize the destination directory with what should actually be in according to the dependency resolution. This means that by setting sync="true", Ivy will not only copy the necessary files, but it will also remove the files which do not need to be there.
+
+The synchronisation actually consists in deleting all filles and directories in the root destination directory which are not required by the retrieve.
+
+The root destination directory is the the directory denoted by the first level up the first token in the destination pattern.
+Example:
+pattern: lib/[conf]/[artifact].[ext]
+root: lib
+
+<span class="since">since 1.4</span> The behaviour is like this when 'useOrigin=true':
+<ul>
+<li>if the artifact is not local, the location from within the cache is used</li>
+<li>if the artifact is a local artifact, it's original location is used</li>
+</ul>
+Note that if resolve has been called separately, the copy to the cache may have occur normally if useOrigin was not set when calling [[ant:resolve]]. If resolve has not been called, it will be called automatically with useOrigin set to the value specified on this task.
+
+<table class="ant">
+<thead>
+    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>pattern</td><td>the pattern to use to copy the dependencies</td>
+        <td>No. Defaults to ${ivy.retrieve.pattern}</td></tr>
+    <tr><td>ivypattern</td><td>the pattern to use to copy the ivy files of dependencies <span class="since">since 1.3</span></td>
+        <td>No. Dependencies ivy files are not retrieved by default.</td></tr>
+    <tr><td>conf</td><td>a comma separated list of the configurations to retrieve</td>
+        <td>No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called</td></tr>
+    <tr><td>sync</td><td>true to synchronize the destination, false to just make a copy <span class="since">since 1.4</span></td>
+        <td>No. Defaults to false</td></tr>
+    <tr><td>type</td><td>comma separated list of accepted artifact types <span class="since">since 1.4</span></td>
+        <td>No. All artifact types are accepted by default.</td></tr>
+    <tr><td>useOrigin</td><td>true to copy artifacts from their original location for local artifacts, false to use only cache locations <span class="since">since 1.4</span></td>
+        <td>No. Defaults to false</td></tr>
+</tbody>
+</table>
+<h1>Examples</h1>
+<code type="xml">
+<ivy:retrieve />
+</code>
+Retrieves dependencies using default parameters. This usually retrieves all the dependencies of the last resolve call to a lib directory.
+
+<hr/>
+<code type="xml">
+<ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]"/>
+</code>
+Retrieves all dependencies of the last resolve call to a lib directory, dependencies being separated in directories named by configuration, each conf directory containing corresponding artifacts without the revision.
+For instance, if the ivy file declares two configurations default and test, the resulting lib dir could look like this:
+<code>
+lib
+  default
+    commons-lang.jar
+    commons-logging.jar
+  test
+    junit.jar
+</code>
+Note that if a dependency is required in the two configurations, it will be copied in the two directories. The download of the dependency is however only made once at resolve time.
+
+<hr/>
+<code type="xml">
+<ivy:retrieve pattern="${lib.dir}/[conf]/[artifact].[ext]" sync="true" />
+</code>
+Same as before, but with synchronisation enabled.
+
+For instance, if the ivy file declares two configurations default and test, the resulting lib dir could look like this:
+<code>
+lib
+  default
+    commons-lang.jar
+    commons-logging.jar
+  test
+    junit.jar
+</code>
+And now suppose commons-logging is no longer part of the dependencies of the default configuration, then a new call to retrieve will result in:
+<code>
+lib
+  default
+    commons-lang.jar
+  test
+    junit.jar
+</code>
+With no synchronisation, commons-logging would not have been removed by the call.
+
+<hr/>
+<code type="xml">
+<ivy:retrieve pattern="${lib.dir}/[type]/[artifact]-[revision].[ext]" conf="runtime"/>
+</code>
+Retrieves only the dependencies of the <code>runtime</code> configuration in directories named by artifact type. The resulting lib dir could look like this:
+<code>
+lib
+  jar
+    commons-lang-1.0.jar
+    looks-1.1.jar
+  source
+    looks-1.1.zip
+</code>
+
+
+<hr/>
+<code type="xml">
+<ivy:retrieve organisation="foo" module="bar" inline="true" pattern="${my.install.dir}/[artifact].[ext]"/>
+</code>
+Resolves and retrieve the latest version of the module bar and its dependencies in the directory pointed by ${my.install.dir}.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/doc/use/retrieve.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/doc/use/var.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/use/var.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/use/var.html (original)
+++ incubator/ivy/core/trunk/doc/doc/use/var.html Wed May  9 03:58:10 2007
@@ -1,56 +1,56 @@
-<!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">
-Sets a variable (by name and value), or set of variables (from file or url) in ivy. <br/>
-Variables are case sensitive.<br/><br/>
-Contrary to ant properties, ivy variables are mutable. But a problem with this is that you do not control when 
-variables are substituted, and usually it is done as soon as possible. So changing the value of a variable will
-have no effect if it has already been substituted. Consequently, <b>using this task is NOT recommended</b>.
-See <a href="../../doc/reference.html">reference</a> page for details about ivy variables.
-<br/><br/>
-  
-<table class="ant">
-<thead>
-    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
-</thead>
-<tbody>
-    <tr><td>name</td><td>the name of the variable to set</td>
-        <td>No</td></tr>
-    <tr><td>value</td><td>the value of the variable to set</td>
-        <td>Yes when using the name attribute</td></tr>
-    <tr><td>file</td><td>the filename of the property file to load as ivy variables</td>
-        <td rowspan="2">One of these, when <b>not</b> using the name attribute</td></tr>
-    <tr><td>url</td><td>the url from which to read ivy variables</td></tr>
-    <tr><td>prefix</td><td>Prefix to apply to variables. A "." is appended to the prefix if not specified.</td>
-        <td>No</td></tr>
-</tbody>
-</table>
-
-	</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+<!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">
+Sets a variable (by name and value), or set of variables (from file or url) in ivy. <br/>
+Variables are case sensitive.<br/><br/>
+Contrary to ant properties, ivy variables are mutable. But a problem with this is that you do not control when 
+variables are substituted, and usually it is done as soon as possible. So changing the value of a variable will
+have no effect if it has already been substituted. Consequently, <b>using this task is NOT recommended</b>.
+See <a href="../../doc/reference.html">reference</a> page for details about ivy variables.
+<br/><br/>
+  
+<table class="ant">
+<thead>
+    <tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>name</td><td>the name of the variable to set</td>
+        <td>No</td></tr>
+    <tr><td>value</td><td>the value of the variable to set</td>
+        <td>Yes when using the name attribute</td></tr>
+    <tr><td>file</td><td>the filename of the property file to load as ivy variables</td>
+        <td rowspan="2">One of these, when <b>not</b> using the name attribute</td></tr>
+    <tr><td>url</td><td>the url from which to read ivy variables</td></tr>
+    <tr><td>prefix</td><td>Prefix to apply to variables. A "." is appended to the prefix if not specified.</td>
+        <td>No</td></tr>
+</tbody>
+</table>
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/doc/use/var.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/doc/yed.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/yed.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/yed.html (original)
+++ incubator/ivy/core/trunk/doc/doc/yed.html Wed May  9 03:58:10 2007
@@ -1,67 +1,67 @@
-<!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">
-<a href="http://www.yworks.com/en/products_yed_about.htm">yEd</a> is a free graph editor, benefiting from
-all the automatic layouts of yFiles. Ivy is able to generate graphs which are readable by yEd.
-
-The graphs generated by ivy are not layed out (in fact it's why we use yEd), so you have to follow a simple sequence of steps to layout the generated graphs.
-
-<h2>Preparation</h2>
-First you have to generate a graphml file. Simply call the report task (see <a href="../doc/use.html">ivy use documentation</a>) for that.
-
-<h2>Step 1: open the graphml file</h2>
-Launch yEd editor, and open the graphml file generated by the report task. You should obtain something like this:
-<center>
-<img src="../images/yed-step1.JPG"/><br/>
-</center>
-
-<h2>Step 2: ask yEd to adjust nodes size</h2>
-<center>
-<img src="../images/yed-step2.JPG"/><br/>
-<img src="../images/yed-step3.JPG"/><br/>
-<img src="../images/yed-step3-2.JPG"/><br/>
-</center>
-
-<h2>Step 3: ask yEd to layout nodes</h2>
-<center>
-<img src="../images/yed-step4.JPG"/><br/>
-<img src="../images/yed-step5.JPG"/><br/>
-<img src="../images/yed-step6.JPG"/><br/>
-
-That's all, you should have obtained something like this:
-
-<img src="../images/yed-step7.JPG"/><br/>
-
-Note that this is only one possibility, test the available layouts yourself, you could find one better in your case.
-Once you have layed out the graph, you can either save it with in the same file (but be warned that it will be overwritten at next ivy report call), or another file, export it to jpg, gif, svg, etc. (see <a href="http://www.yworks.com/en/products_yed_about.htm">yEd</a> site for details).
-</center>
-
-
-	</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+<!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">
+<a href="http://www.yworks.com/en/products_yed_about.htm">yEd</a> is a free graph editor, benefiting from
+all the automatic layouts of yFiles. Ivy is able to generate graphs which are readable by yEd.
+
+The graphs generated by ivy are not layed out (in fact it's why we use yEd), so you have to follow a simple sequence of steps to layout the generated graphs.
+
+<h2>Preparation</h2>
+First you have to generate a graphml file. Simply call the report task (see <a href="../doc/use.html">ivy use documentation</a>) for that.
+
+<h2>Step 1: open the graphml file</h2>
+Launch yEd editor, and open the graphml file generated by the report task. You should obtain something like this:
+<center>
+<img src="../images/yed-step1.JPG"/><br/>
+</center>
+
+<h2>Step 2: ask yEd to adjust nodes size</h2>
+<center>
+<img src="../images/yed-step2.JPG"/><br/>
+<img src="../images/yed-step3.JPG"/><br/>
+<img src="../images/yed-step3-2.JPG"/><br/>
+</center>
+
+<h2>Step 3: ask yEd to layout nodes</h2>
+<center>
+<img src="../images/yed-step4.JPG"/><br/>
+<img src="../images/yed-step5.JPG"/><br/>
+<img src="../images/yed-step6.JPG"/><br/>
+
+That's all, you should have obtained something like this:
+
+<img src="../images/yed-step7.JPG"/><br/>
+
+Note that this is only one possibility, test the available layouts yourself, you could find one better in your case.
+Once you have layed out the graph, you can either save it with in the same file (but be warned that it will be overwritten at next ivy report call), or another file, export it to jpg, gif, svg, etc. (see <a href="http://www.yworks.com/en/products_yed_about.htm">yEd</a> site for details).
+</center>
+
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/doc/yed.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/download.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/download.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/download.html (original)
+++ incubator/ivy/core/trunk/doc/download.html Wed May  9 03:58:10 2007
@@ -1,29 +1,29 @@
-<!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>
+<!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">
 <h2>Disclaimer</h2>
 <code>
@@ -107,7 +107,7 @@
 
 To have info about the different kind of distributions, see <a href="choose-distrib.html">that page</a>.
 For previous version information and download, see the <a href="doc/releasenotes.html">release notes page</a> in the documentation.
-</textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/download.html
------------------------------------------------------------------------------
    svn:eol-style = LF

Modified: incubator/ivy/core/trunk/doc/faq.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/faq.html?view=diff&rev=536488&r1=536487&r2=536488
==============================================================================
--- incubator/ivy/core/trunk/doc/faq.html (original)
+++ incubator/ivy/core/trunk/doc/faq.html Wed May  9 03:58:10 2007
@@ -1,145 +1,145 @@
-<!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>What and Why</h1>
-<h2>What is Ivy ?</h2>
-<p>Ivy is a powerful dependencies manager with transitive dependencies support and much more <a href="features.html">features</a>.</p>
-<p>With Ivy you define the dependencies of your module in an xml file, called an ivy file. Then you usually ask ivy to retrieve your dependencies to a local lib dir, and it does it for you by locating the artifacts of your dependencies in repositories, such as ibiblio.</p>
-<h2>Why should I use a dependencies manager ?</h2>
-<p>Without a dependencies manager, two solutions are often used to store the dependencies of a project: a project lib dir or direct access to a shared repository.<br />
-The major drawback of the project lib dir is that the same dependencies are stored in multiple location if you have several projects using the same dependencies. Moreover, we often see project where dependencies revisions are not documented, which can cause problems for maintenance.<br />
-With the shared repository the problem is often to maintain the list of dependencies of the project. This list is often lost within the build file, which does not help maintenance. Moreover, this solution often requires a download of the whole repository, unless home made dependencies management solution has been used.</p>
-<p>Finally, the major drawback of these solutions is that they do not use transitive dependencies. Transitive dependencies are the dependencies of your dependencies. Managing transitive dependencies  let you declare dependencies only on what you really need, and not what the module you use themselves need. This not only eases your dependencies declaration, but it also improves a lot the maintenability of your project, especially in multi-project environment. Imagine you develop a component used in several other projects. Then each time your component needs a new dependency, without transitive dependencies, you have to update all the projects using your component ! And this could really take a lot of time !</p>
-<h2>Why should I use Ivy ?</h2>
-<p>If you are convinced of using a dependencies manager, you may wonder why using Ivy and not another tool. We are not able to answer this question without being biased, but have a look at Ivy <a href="features.html">features</a> and the <a href="doc/m2comparison.html">product comparison</a> we provide, and you will certainly see that Ivy is one of the best dependencies manager currently available ;-)</p>
-<h2>How does Ivy differ from Maven2 ?</h2>
-<p>The answer to this question is too long, so it deserves its own page <a href="doc/m2comparison.html">here</a>.</p>
-<h1>Ivy in use</h1>
-<h2>I don't understand what's happening...</h2>
-<p>The first thing to do when you don't understand what's going wrong is to try to change the message level. If you use ant, you can use the -debug or -verbose options to get more detailed messages and better understand what's happening.</p>
-<h2>Ivy seems to fail connecting to ibiblio...</h2>
-<p>First, check if the ibiblio site is ok with your favorite browser. If the site is ok, maybe it's a problem of proxy configuration. Set your ANT_OPTS environment variable<br />
-to configure your proxy if you have one.<br />
-For instance:<br />
-<code>set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128</code></p>
-<p>If it still doesn't work, maybe it's your dependency file which is not ok. Check<br />
-if the module name you depend on is actually a name of directory under<br />
-<a href="http://www.ibiblio.org/maven/" title="www.ibiblio.org/maven/">www.ibiblio.org/maven/</a>. If this is the case, check if the jar with a name like<br />
-[module]-[revision].jar is present under the jars directory of this module on ibiblio.<br />
-For instance: <a href="http://www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar" title="www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar">www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar</a></p>
-<p>If this is the case, check your ivy configuration to see if you actually use the ibiblio<br />
-or ivyrep resolver.</p>
-<p>Finally, you can check if the files were not downloaded but corrupted<br />
-(Ivy has no md5 checking for the moment) by checking your lib directory and opening<br />
-the jars if any with an unzip program.</p>
-<p>If you still have problems post on the <a href="forum/core.html">forum</a><br />
-mentioning your OS, your version of ant, your version of ivy, your configuration file<br />
-and your ivy file.</p>
-<h2>Ivy fails to get an artifact / ivy file on my http server. What's wrong?</h2>
-<p>The first thing to do is to ensure the setting is correct. Ivy should log the url it tried, copy this url and paste it in your favorite browser, and verify you get no error.</p>
-<p>If this is ok, check if you don't need any proxy setting nor authentication. For proxy setting, you can use for instance this:<br />
-<code>set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128</code><br />
-For authentication, fill in the appropriate data at <a href="doc/use/configure.html">configuration</a> time.</p>
-<p>If you still have no idea of what is wrong, then I suggest to use commons-httpclient if it isn't already the case (you should just put commons-httpclient in you classpath), and then <a href="http://jakarta.apache.org/commons/httpclient/logging.html">turn on the debug logging</a>.</p>
-<p>You will then have very detailed information on how your url is handled. If you still have problem, ask for help on the <a href="forum/core.html">forum</a>.</p>
-<h2>What if I do not want to put my library files in the lib directory ? </h2>
-<p>No problem, you just have to set an ant property:</p>
-<code><property name="ivy.lib.dir" value="pathtomylibdir"/></code>
-<h2>What if I do not want the revision of the files I retrieve to appear in the<br />
-file name ?</h2>
-<p>A typical question for people using an IDE like eclipse and often changing<br />
-dependency revision: it's a bit boring to change your IDE project just to tell<br />
-him to use comp-build2596.jar instead of comp-build2595.jar, when you have<br />
-already changed your ivy file (and even if you haven't changed it, if you use<br />
-the continuous integration feature !). No problem, you have a total control on<br />
-the files retrieved using the pattern attribute in the retrieve task:</p>
-<p>Here is the default pattern:</p>
-<code><ivy:retrieve pattern="${ivy.lib.dir}/[artifact]-[revision].[ext]"/></code>
-<p>And here is one which do not suffix file name with dependency revision:</p>
-<code><ivy:retrieve pattern="${ivy.lib.dir}/[artifact].[ext]"/></code>
-<p>And one which makes your lib directory have the same layout as the ibiblio repository:</p>
-<code><ivy:retrieve pattern="${ivy.lib.dir}/[module]/[type]s/[artifact]-[revision].[ext]"/></code>
-<p>Not too difficult, and really flexible, isn't it ? And check the retrieve task<br />
-reference documentation to learn more about it...</p>
-<h2>Why two xml files ?</h2>
-<p>Ivy uses two types of xml files: configuration files and ivy files.</p>
-<p>In fact, Ivy distinguishes two different steps to describe and get your<br />
-dependencies:<br />
-You write ivy files to describe the dependencies of your module, independently of how you retrieve them.<br />
-Then you configure ivy to indicate where it can find your dependencies. Thus you can easily share your ivy files, even if you have internal dependencies which are not resolved the same way in your environment as in the target development environment. You just need to write two configuration files, one in your default development environment, and one in the target development environment with the <b>same ivy files</b>. </p>
-<h2>How do I separate the dependencies I need at xxx time and the one I need at yyy time ?</h2>
-<p>Ivy uses a concept called <i>configurations</i> to handle this, and many more. As explained in the <a href="doc/terminology.html">terminology page</a>, a <i>configuration</i> of your module can be thought as a way to use your module (<i>note: this has nothing to do with the configuration of ivy itself, through the use of configuration file</i>). You can describe what dependencies are needed in each configuration. </p>
-<p>Moreover, because the dependencies are modules too, they can also have configurations. What is extremely powerful with ivy is that you can define configurations mapping, i.e. which conf of the dependency is needed in which conf of your module. Thus what is needed at 'runtime' of a dependency can be needed for 'test' of your module.</p>
-<p>Finally, the configurations are unlimited, defined in each module, and can extend each other. This contributes a lot to ivy flexibility.</p>
-<h2>How do I configure Ivy to find ivy files in both a local repository and ivyrep ?</h2>
-<p>A frequent configuration of Ivy is to use a local repository + ivyrep + ibiblio to store ivy files and artifacts.<br />
-Here is a sample configuration to do this:</p>
-<code>
-<ivysettings>
-  <properties file="${ivy.settings.dir}/ivysettings.properties"/>
-  <conf defaultCache="cache" defaultResolver="libraries"/>
-  <resolvers>
-    <dual name="libraries" >
-      <chain name="ivy-chain" returnFirst="true">
-        <filesystem name="local-ivy"> 
-          <ivy pattern="${locallibrep}/[organisation]/[module]/[revision]/ivy.xml" /> 
-        </filesystem>
-        <ivyrep name="ivyrep"/>
-      </chain>
-      <chain name="artifact-chain" returnFirst="true">
-        <filesystem name="local-artifact"> 
-          <artifact pattern="${locallibrep}/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" /> 
-        </filesystem>
-        <ibiblio name="ibiblio"/>
-      </chain>
-    </dual>
-  </resolvers> 
-</ivysettings>
-</code>
-<h2>Can I write an ivy file for a module with no artifact at all ?</h2>
-<p>Yes, this is what is called a 'virtual' module.</p>
-<p>Having a module which has no publication and only dependencies can be useful in many cases. </p>
-<p>In particular, you can in this way define a set of dependencies used in several projects. Once defined, you can simply add a dependency on this virtual module to get all its dependencies, thanks to transitive dependencies management.</p>
-<p>It can also be useful if you want to define a flexible framework. In your framework, you will certainly have several modules, each having its own dependencies. But for the users of your framework, it can be interesting to provide a virtual module, representing the framework as a whole, and using configurations to let the user choose what he really wants to use in your framework, in a very flexible and effective way.</p>
-<p>But the problem is that ivy considers by default that a module publishes one artifact, with the same name as the module itself. So the way to define a virtual module is to add to its ivy file a publications section with no publication inside:</p>
-<code><publications/></code>
-<h2>I do not manage to get xxx module on ibiblio. What's wrong ?</h2>
-<p>The problem can come from several places... usually it comes from the fact that some modules on ibiblio do not respect a clean structure.</p>
-<p>For instance, opensymphony projects are all in an opensymphony directory, which does not respect the [module]/[artifact]-[revision].[ext] pattern. In this case the only way to go with this is to configure another resolver with the appropriate pattern, and configure ivy to use this resolver for opensymphony only.</p>
-<p>Another similar problem is to have several modules in one directory, such xerces and xmlapis in the xerces directory. The problem is that if you consider the two as one module, you will be tempted to declare a dependency on two revisions of this module. This is not the right approach, because this does not match ivy definition of a module. A better approach is similar to the preceding one with a special configuration for this only.</p>
-<p>Another solution is to setup a local repository for those modules that are not cleanly deployed on ibiblio. Using this local repository first and the ibiblio repository after is a good way to turn around the problems of ibiblio and still benefit from the huge number of artifacts that can be found.</p>
-<h2>When I update an ivy file in my repository ivy do not take the change into account. Is this normal ?</h2>
-<p>This the default behaviour of ivy, which relies on the revision and on its cache to avoid too many downloads. However, this can be changed on each resolver using the <em>checkmodified</em> attribute, or globally by setting <em>ivy.resolver.default.check.modified</em> variable to true.</p>
-<h1>Misc</h1>
-<h2>Where are the release notes ?</h2>
-<p>Release notes can be found in the <a href="doc/releasenotes.html">documentation</a>.</p>
-<h2>Where can I get more information?</h2>
-<p>If you need more information about Ivy than the one found in the documentation, you can see the <a href="links.html">links</a> page, use the <a href="forum/core.html">forum</a> to ask your question to the community, or use your favorite search engine.<br />
-For search engine search, we advise to use ivy + ant or java as base keywords, since ivy alone is a very common word.</p></textarea>
-<script type="text/javascript">xooki.postProcess();</script>
-</body>
-</html>
+<!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>What and Why</h1>
+<h2>What is Ivy ?</h2>
+<p>Ivy is a powerful dependencies manager with transitive dependencies support and much more <a href="features.html">features</a>.</p>
+<p>With Ivy you define the dependencies of your module in an xml file, called an ivy file. Then you usually ask ivy to retrieve your dependencies to a local lib dir, and it does it for you by locating the artifacts of your dependencies in repositories, such as ibiblio.</p>
+<h2>Why should I use a dependencies manager ?</h2>
+<p>Without a dependencies manager, two solutions are often used to store the dependencies of a project: a project lib dir or direct access to a shared repository.<br />
+The major drawback of the project lib dir is that the same dependencies are stored in multiple location if you have several projects using the same dependencies. Moreover, we often see project where dependencies revisions are not documented, which can cause problems for maintenance.<br />
+With the shared repository the problem is often to maintain the list of dependencies of the project. This list is often lost within the build file, which does not help maintenance. Moreover, this solution often requires a download of the whole repository, unless home made dependencies management solution has been used.</p>
+<p>Finally, the major drawback of these solutions is that they do not use transitive dependencies. Transitive dependencies are the dependencies of your dependencies. Managing transitive dependencies  let you declare dependencies only on what you really need, and not what the module you use themselves need. This not only eases your dependencies declaration, but it also improves a lot the maintenability of your project, especially in multi-project environment. Imagine you develop a component used in several other projects. Then each time your component needs a new dependency, without transitive dependencies, you have to update all the projects using your component ! And this could really take a lot of time !</p>
+<h2>Why should I use Ivy ?</h2>
+<p>If you are convinced of using a dependencies manager, you may wonder why using Ivy and not another tool. We are not able to answer this question without being biased, but have a look at Ivy <a href="features.html">features</a> and the <a href="doc/m2comparison.html">product comparison</a> we provide, and you will certainly see that Ivy is one of the best dependencies manager currently available ;-)</p>
+<h2>How does Ivy differ from Maven2 ?</h2>
+<p>The answer to this question is too long, so it deserves its own page <a href="doc/m2comparison.html">here</a>.</p>
+<h1>Ivy in use</h1>
+<h2>I don't understand what's happening...</h2>
+<p>The first thing to do when you don't understand what's going wrong is to try to change the message level. If you use ant, you can use the -debug or -verbose options to get more detailed messages and better understand what's happening.</p>
+<h2>Ivy seems to fail connecting to ibiblio...</h2>
+<p>First, check if the ibiblio site is ok with your favorite browser. If the site is ok, maybe it's a problem of proxy configuration. Set your ANT_OPTS environment variable<br />
+to configure your proxy if you have one.<br />
+For instance:<br />
+<code>set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128</code></p>
+<p>If it still doesn't work, maybe it's your dependency file which is not ok. Check<br />
+if the module name you depend on is actually a name of directory under<br />
+<a href="http://www.ibiblio.org/maven/" title="www.ibiblio.org/maven/">www.ibiblio.org/maven/</a>. If this is the case, check if the jar with a name like<br />
+[module]-[revision].jar is present under the jars directory of this module on ibiblio.<br />
+For instance: <a href="http://www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar" title="www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar">www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar</a></p>
+<p>If this is the case, check your ivy configuration to see if you actually use the ibiblio<br />
+or ivyrep resolver.</p>
+<p>Finally, you can check if the files were not downloaded but corrupted<br />
+(Ivy has no md5 checking for the moment) by checking your lib directory and opening<br />
+the jars if any with an unzip program.</p>
+<p>If you still have problems post on the <a href="forum/core.html">forum</a><br />
+mentioning your OS, your version of ant, your version of ivy, your configuration file<br />
+and your ivy file.</p>
+<h2>Ivy fails to get an artifact / ivy file on my http server. What's wrong?</h2>
+<p>The first thing to do is to ensure the setting is correct. Ivy should log the url it tried, copy this url and paste it in your favorite browser, and verify you get no error.</p>
+<p>If this is ok, check if you don't need any proxy setting nor authentication. For proxy setting, you can use for instance this:<br />
+<code>set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128</code><br />
+For authentication, fill in the appropriate data at <a href="doc/use/configure.html">configuration</a> time.</p>
+<p>If you still have no idea of what is wrong, then I suggest to use commons-httpclient if it isn't already the case (you should just put commons-httpclient in you classpath), and then <a href="http://jakarta.apache.org/commons/httpclient/logging.html">turn on the debug logging</a>.</p>
+<p>You will then have very detailed information on how your url is handled. If you still have problem, ask for help on the <a href="forum/core.html">forum</a>.</p>
+<h2>What if I do not want to put my library files in the lib directory ? </h2>
+<p>No problem, you just have to set an ant property:</p>
+<code><property name="ivy.lib.dir" value="pathtomylibdir"/></code>
+<h2>What if I do not want the revision of the files I retrieve to appear in the<br />
+file name ?</h2>
+<p>A typical question for people using an IDE like eclipse and often changing<br />
+dependency revision: it's a bit boring to change your IDE project just to tell<br />
+him to use comp-build2596.jar instead of comp-build2595.jar, when you have<br />
+already changed your ivy file (and even if you haven't changed it, if you use<br />
+the continuous integration feature !). No problem, you have a total control on<br />
+the files retrieved using the pattern attribute in the retrieve task:</p>
+<p>Here is the default pattern:</p>
+<code><ivy:retrieve pattern="${ivy.lib.dir}/[artifact]-[revision].[ext]"/></code>
+<p>And here is one which do not suffix file name with dependency revision:</p>
+<code><ivy:retrieve pattern="${ivy.lib.dir}/[artifact].[ext]"/></code>
+<p>And one which makes your lib directory have the same layout as the ibiblio repository:</p>
+<code><ivy:retrieve pattern="${ivy.lib.dir}/[module]/[type]s/[artifact]-[revision].[ext]"/></code>
+<p>Not too difficult, and really flexible, isn't it ? And check the retrieve task<br />
+reference documentation to learn more about it...</p>
+<h2>Why two xml files ?</h2>
+<p>Ivy uses two types of xml files: configuration files and ivy files.</p>
+<p>In fact, Ivy distinguishes two different steps to describe and get your<br />
+dependencies:<br />
+You write ivy files to describe the dependencies of your module, independently of how you retrieve them.<br />
+Then you configure ivy to indicate where it can find your dependencies. Thus you can easily share your ivy files, even if you have internal dependencies which are not resolved the same way in your environment as in the target development environment. You just need to write two configuration files, one in your default development environment, and one in the target development environment with the <b>same ivy files</b>. </p>
+<h2>How do I separate the dependencies I need at xxx time and the one I need at yyy time ?</h2>
+<p>Ivy uses a concept called <i>configurations</i> to handle this, and many more. As explained in the <a href="doc/terminology.html">terminology page</a>, a <i>configuration</i> of your module can be thought as a way to use your module (<i>note: this has nothing to do with the configuration of ivy itself, through the use of configuration file</i>). You can describe what dependencies are needed in each configuration. </p>
+<p>Moreover, because the dependencies are modules too, they can also have configurations. What is extremely powerful with ivy is that you can define configurations mapping, i.e. which conf of the dependency is needed in which conf of your module. Thus what is needed at 'runtime' of a dependency can be needed for 'test' of your module.</p>
+<p>Finally, the configurations are unlimited, defined in each module, and can extend each other. This contributes a lot to ivy flexibility.</p>
+<h2>How do I configure Ivy to find ivy files in both a local repository and ivyrep ?</h2>
+<p>A frequent configuration of Ivy is to use a local repository + ivyrep + ibiblio to store ivy files and artifacts.<br />
+Here is a sample configuration to do this:</p>
+<code>
+<ivysettings>
+  <properties file="${ivy.settings.dir}/ivysettings.properties"/>
+  <conf defaultCache="cache" defaultResolver="libraries"/>
+  <resolvers>
+    <dual name="libraries" >
+      <chain name="ivy-chain" returnFirst="true">
+        <filesystem name="local-ivy"> 
+          <ivy pattern="${locallibrep}/[organisation]/[module]/[revision]/ivy.xml" /> 
+        </filesystem>
+        <ivyrep name="ivyrep"/>
+      </chain>
+      <chain name="artifact-chain" returnFirst="true">
+        <filesystem name="local-artifact"> 
+          <artifact pattern="${locallibrep}/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" /> 
+        </filesystem>
+        <ibiblio name="ibiblio"/>
+      </chain>
+    </dual>
+  </resolvers> 
+</ivysettings>
+</code>
+<h2>Can I write an ivy file for a module with no artifact at all ?</h2>
+<p>Yes, this is what is called a 'virtual' module.</p>
+<p>Having a module which has no publication and only dependencies can be useful in many cases. </p>
+<p>In particular, you can in this way define a set of dependencies used in several projects. Once defined, you can simply add a dependency on this virtual module to get all its dependencies, thanks to transitive dependencies management.</p>
+<p>It can also be useful if you want to define a flexible framework. In your framework, you will certainly have several modules, each having its own dependencies. But for the users of your framework, it can be interesting to provide a virtual module, representing the framework as a whole, and using configurations to let the user choose what he really wants to use in your framework, in a very flexible and effective way.</p>
+<p>But the problem is that ivy considers by default that a module publishes one artifact, with the same name as the module itself. So the way to define a virtual module is to add to its ivy file a publications section with no publication inside:</p>
+<code><publications/></code>
+<h2>I do not manage to get xxx module on ibiblio. What's wrong ?</h2>
+<p>The problem can come from several places... usually it comes from the fact that some modules on ibiblio do not respect a clean structure.</p>
+<p>For instance, opensymphony projects are all in an opensymphony directory, which does not respect the [module]/[artifact]-[revision].[ext] pattern. In this case the only way to go with this is to configure another resolver with the appropriate pattern, and configure ivy to use this resolver for opensymphony only.</p>
+<p>Another similar problem is to have several modules in one directory, such xerces and xmlapis in the xerces directory. The problem is that if you consider the two as one module, you will be tempted to declare a dependency on two revisions of this module. This is not the right approach, because this does not match ivy definition of a module. A better approach is similar to the preceding one with a special configuration for this only.</p>
+<p>Another solution is to setup a local repository for those modules that are not cleanly deployed on ibiblio. Using this local repository first and the ibiblio repository after is a good way to turn around the problems of ibiblio and still benefit from the huge number of artifacts that can be found.</p>
+<h2>When I update an ivy file in my repository ivy do not take the change into account. Is this normal ?</h2>
+<p>This the default behaviour of ivy, which relies on the revision and on its cache to avoid too many downloads. However, this can be changed on each resolver using the <em>checkmodified</em> attribute, or globally by setting <em>ivy.resolver.default.check.modified</em> variable to true.</p>
+<h1>Misc</h1>
+<h2>Where are the release notes ?</h2>
+<p>Release notes can be found in the <a href="doc/releasenotes.html">documentation</a>.</p>
+<h2>Where can I get more information?</h2>
+<p>If you need more information about Ivy than the one found in the documentation, you can see the <a href="links.html">links</a> page, use the <a href="forum/core.html">forum</a> to ask your question to the community, or use your favorite search engine.<br />
+For search engine search, we advise to use ivy + ant or java as base keywords, since ivy alone is a very common word.</p></textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Propchange: incubator/ivy/core/trunk/doc/faq.html
------------------------------------------------------------------------------
    svn:eol-style = LF



Mime
View raw message