svn commit: r488342 [1/9] - in /incubator/ivy/trunk/src/doc/xooki: ./ doc/ doc/conf/ doc/configuration/ doc/configuration/macrodef/ doc/configuration/namespace/ doc/ivyfile/ doc/releasenotes/ doc/resolver/ doc/tutorial/ doc/tutorial/build-repository/ d...

[xa...@apache.org]

Author: xavier
Date: Mon Dec 18 09:06:07 2006
New Revision: 488342

URL: http://svn.apache.org/viewvc?view=rev&rev=488342
Log:
doc import in xooki format: mere generation using ruby script, still require review, especially on images (not handled by script) and links (most links are ok, but those pointing outside the documentation book -like features for example- are not imported yet

Added:
    incubator/ivy/trunk/src/doc/xooki/
    incubator/ivy/trunk/src/doc/xooki/config.json
    incubator/ivy/trunk/src/doc/xooki/doc/
    incubator/ivy/trunk/src/doc/xooki/doc.html
    incubator/ivy/trunk/src/doc/xooki/doc/ant.html
    incubator/ivy/trunk/src/doc/xooki/doc/appendix.html
    incubator/ivy/trunk/src/doc/xooki/doc/bestpractices.html
    incubator/ivy/trunk/src/doc/xooki/doc/concept.html
    incubator/ivy/trunk/src/doc/xooki/doc/conf/
    incubator/ivy/trunk/src/doc/xooki/doc/conf/triggers.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/
    incubator/ivy/trunk/src/doc/xooki/doc/configuration.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/classpath.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/conflict-managers.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/include.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/latest-strategies.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/macrodef/
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/macrodef.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/macrodef/attribute.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/module.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/modules.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace/
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace/dest.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace/fromtosystem.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace/rule.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespace/src.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/namespaces.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/outputters.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/parsers.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/properties.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/property.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/resolvers.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/status.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/statuses.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/typedef.html
    incubator/ivy/trunk/src/doc/xooki/doc/configuration/version-matchers.html
    incubator/ivy/trunk/src/doc/xooki/doc/extend.html
    incubator/ivy/trunk/src/doc/xooki/doc/install.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/artifact-conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/artifact-exclude-conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/artifact-exclude.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/artifact.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/configurations.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/conflicts.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependencies.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency-artifact-conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency-artifact.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency-conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency-include-conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency-include.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/dependency.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/description.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/include.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/info.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/ivyauthor.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/license.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/manager.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/mapped.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/publications.html
    incubator/ivy/trunk/src/doc/xooki/doc/ivyfile/repository.html
    incubator/ivy/trunk/src/doc/xooki/doc/m2comparison.html
    incubator/ivy/trunk/src/doc/xooki/doc/moreexamples.html
    incubator/ivy/trunk/src/doc/xooki/doc/principle.html
    incubator/ivy/trunk/src/doc/xooki/doc/reference.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.5.1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.5.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.6.1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.6.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.7.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.8.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/0.9.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.0-rc1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.0-rc2.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.0-rc3.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.0.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.2a.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.3-rc1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.3-rc2.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.3-rc3.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.3.1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.3.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.4-RC1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.4-RC2.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.4.1.html
    incubator/ivy/trunk/src/doc/xooki/doc/releasenotes/1.4.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/chain.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/dual.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/filesystem.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/ibiblio.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/ivyrep.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/sftp.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/ssh.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/url.html
    incubator/ivy/trunk/src/doc/xooki/doc/resolver/vfs.html
    incubator/ivy/trunk/src/doc/xooki/doc/standalone.html
    incubator/ivy/trunk/src/doc/xooki/doc/terminology.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/build-repository/
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/build-repository.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/build-repository/advanced1.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/build-repository/advanced2.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/build-repository/basic.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/conf.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/defaultconf.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/dual.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/ivyrep.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/multi-project.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/multiple.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/multiproject.html
    incubator/ivy/trunk/src/doc/xooki/doc/tutorial/start.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/
    incubator/ivy/trunk/src/doc/xooki/doc/use.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/artifactproperty.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/artifactreport.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/buildlist.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/buildnumber.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/cachefileset.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/cachepath.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/configure.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/deliver.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/findrevision.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/info.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/install.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/listmodules.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/postresolvetask.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/publish.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/report.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/repreport.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/resolve.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/retrieve.html
    incubator/ivy/trunk/src/doc/xooki/doc/use/var.html
    incubator/ivy/trunk/src/doc/xooki/doc/yed.html
    incubator/ivy/trunk/src/doc/xooki/images/
    incubator/ivy/trunk/src/doc/xooki/images/apache-incubator-logo.png   (with props)
    incubator/ivy/trunk/src/doc/xooki/images/logo.png   (with props)
    incubator/ivy/trunk/src/doc/xooki/ivyrep.html
    incubator/ivy/trunk/src/doc/xooki/printTemplate.html
    incubator/ivy/trunk/src/doc/xooki/style/
    incubator/ivy/trunk/src/doc/xooki/style/ant.css
    incubator/ivy/trunk/src/doc/xooki/style/color.css
    incubator/ivy/trunk/src/doc/xooki/style/ivy-ref.css
    incubator/ivy/trunk/src/doc/xooki/style/nav.css
    incubator/ivy/trunk/src/doc/xooki/style/shell.css
    incubator/ivy/trunk/src/doc/xooki/style/style.css
    incubator/ivy/trunk/src/doc/xooki/template.html
    incubator/ivy/trunk/src/doc/xooki/toc.json
    incubator/ivy/trunk/src/doc/xooki/xooki/
    incubator/ivy/trunk/src/doc/xooki/xooki/blankPageTpl.html
    incubator/ivy/trunk/src/doc/xooki/xooki/images/
    incubator/ivy/trunk/src/doc/xooki/xooki/images/addchild.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/bullet.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/closed.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/debug.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/delete.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/down.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/edit.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/open.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/save.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/images/up.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/messages.json
    incubator/ivy/trunk/src/doc/xooki/xooki/tiddly/
    incubator/ivy/trunk/src/doc/xooki/xooki/tiddly/util.js
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/closed.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/list.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/open.gif   (with props)
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/simpletree.css
    incubator/ivy/trunk/src/doc/xooki/xooki/tree/simpletreemenu.js
    incubator/ivy/trunk/src/doc/xooki/xooki/trimpath/
    incubator/ivy/trunk/src/doc/xooki/xooki/trimpath/template.js
    incubator/ivy/trunk/src/doc/xooki/xooki/xooki.js
    incubator/ivy/trunk/src/doc/xooki/xooki/xookiEdit.js

Added: incubator/ivy/trunk/src/doc/xooki/config.json
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/config.json?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/config.json (added)
+++ incubator/ivy/trunk/src/doc/xooki/config.json Mon Dec 18 09:06:07 2006
@@ -0,0 +1 @@
+{debug:true, jira: {ids: ['IVY'], url: 'http://issues.apache.org/jira'}}

Added: incubator/ivy/trunk/src/doc/xooki/doc.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,46 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 0};</script>	
+	<script type="text/javascript" src="xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+Welcome to the official Ivy documentation.
+
+<h1>What is Ivy?</h1>
+Ivy is an agile dependency manager, primarily focused on managing java dependencies.
+Ivy is open source and released under a very permissive <a href="license.html">BSD license</a>.
+Ivy has a lot of powerful <a href="features.html">features</a>, the most popular and useful being its flexibily, integration with ant, and its strong transitive dependencies management engine.
+The transitive dependencies management is a feature which let you get dependencies of your dependencies, transitively. In order to address this problematic ivy needs to find metadata about your modules, usually in an <a href="doc/ivyfile.html">ivy file</a>. To find these metadata and your dependencies artifacts (usually jars), Ivy can be configured to use a lot of different <a href="doc/configuration/resolvers.html">repositories</a>.
+
+<h1>About this doc</h1>
+If you browse this documentation from your installation of ivy, you can also check the <a href="http://www.jayasoft.org/ivy/doc">online version</a> for latest updates and comments. To easily navigate to the online version, you will find a link to the corresponding online version on each page just after the title.
+
+The online version of this documentation is updated periodically, especially when new features are added during development. So if you find something documented here not available in your version of ivy, it may be because it is available only with the latest <a href="download.html">download</a>.
+
+If you want to view the whole documentation in a single printer-friendly page, please use the <a href="doc/print.html">printer-friendly link</a> at the bottom of any documentation page in the online documentation.
+
+<h1>Other places to go</h1>
+Check Ivy <a href="features.html">features</a>. 
+Read our <a href="faq.html">FAQ</a>.
+Ask for help on our <a href="forum.html">forum</a>.
+Report bug or feature request in our <a href="./issues">issue tracking system</a>.
+Check <a href="links.html">external tools and resources</a>.
+
+<h1>Overview</h1>
+This documentation is decomposed in 3 main parts:
+<ul>
+  <li><a href="doc/tutorial.html">Tutorials</a></li> 
+The tutorials is the best way to begin to play with ivy. You will easily and quickly learn the basics of Ivy.
+  <li><a href="doc/reference.html">Reference</a></li> 
+The reference documentation gives you all the details of Ivy. 
+The introduction part is particularly useful: it defines some vocabulary, explains main concepts such as dependency resolvers and patterns, and give an overview on how ivy works internally. 
+It's also in the reference doc that you will find all you always dreamed to know about ivy configuration, ivy files, and ivy use (especially with ant).
+  <li><a href="doc/appendix.html">Appendix</a></li> 
+The appendix section contains a bunch of Ivy related information which is not part of Ivy reference doc.
+</ul>
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/ant.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/ant.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/ant.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/ant.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,133 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 1};</script>	
+	<script type="text/javascript" src="../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+The main and most frequent way to use ivy is from an ant build file. However, ivy can also be called as a standalone application
+
+If you use ant version <b>1.6.0</b> or superior, you just have to add ivy namespace to your project (<code>xmlns:ivy="antlib:fr.jayasoft.ivy.ant"</code> attribute of your project tag), and you can call ivy tasks.
+
+If you want to make your build handle ivy.jar in either ant lib dir or a local lib dir, you can follow <a href="./node/233">this tip</a> given by colin sampaleanu.
+
+If you use ant <b>1.5.1</b> or superior, you have to define the tasks you use in your build file. For instance:
+<code>
+  <taskdef name="ivy-configure" classname="fr.jayasoft.ivy.ant.IvyConfigure"/>
+  <taskdef name="ivy-resolve" classname="fr.jayasoft.ivy.ant.IvyResolve"/>
+  <taskdef name="ivy-retrieve" classname="fr.jayasoft.ivy.ant.IvyRetrieve"/>
+  <taskdef name="ivy-deliver" classname="fr.jayasoft.ivy.ant.IvyDeliver"/> 
+  <taskdef name="ivy-publish" classname="fr.jayasoft.ivy.ant.IvyPublish"/>
+</code>
+<em>Note: the tasks listed above are non exhaustive. For a complete list of tasks with the corresponding classes, see the <a href="http://svn.jayasoft.org/projects/tools/ivy/src/java/fr/jayasoft/ivy/ant/antlib.xml">antlib.xml</a> file in svn or the version you use.</em>
+
+Then you can use the tasks, but check their name, following samples assume you use the ivy namespace (ivy:xxx tasks), whereas with ant 1.5 you cannot use namespace, and should therefore use ivy-xxx tasks if you have followed the taskdefs above.
+
+If you use an ant version lower than 1.5.1, you can not use the ivy tasks... you should then call ivy as any external program.
+<h1>Calling ivy from ant: first steps</h1>
+Once your build file is ok to call ivy tasks, the simplest way to use ivy is to call the ivy retrieve task with no parameters:
+<code>
+<ivy:retrieve />
+</code>
+This calls ivy with default values, which might be ok in several projects. In fact, it is equivalent to:
+<code type="xml">
+<target name="resolve">
+    <ivy:configure />
+    
+    <ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}" />
+    
+    <ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}" />
+</target>
+</code>
+
+Those 3 tasks follow the 3 main steps of ivy retrieving dependencies process:
+<ul>
+<li>First the configure task tells it how it can find dependencies giving it a path to an <a href="../doc/configuration.html">xml configuration file</a>.</li> 
+<li>Then the resolve task actually resolve dependencies described by an <a href="../doc/ivyfile.html">ivy file</a>, and put those dependencies in the ivy cache (a directory configured in the configuration file).</li>
+<li>Finally the retrieve task copies dependencies from the cache to anywhere you want in your file system. You can then use those dependencies to make your classpath with standard ant paths.</li>
+</ul>
+
+To understand more accurately the behaviour of ivy tasks, one should know that a property file is loaded in ant by ivy at the beginning of the configure call. This property file contains the following properties:
+<code>
+ivy.project.dir = ${basedir}
+ivy.lib.dir = ${ivy.project.dir}/lib
+ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
+ivy.distrib.dir = ${ivy.project.dir}/distrib
+	
+ivy.resolver.default.check.modified = false
+ivy.default.always.check.exact.revision = true
+
+ivy.configurations = *
+ivy.resolve.default.type.filter = *
+ivy.status = integration
+ivy.dep.file = ivy.xml
+ivy.conf.file = ivyconf.xml
+ivy.retrieve.pattern = ${ivy.lib.dir}/[artifact]-[revision].[ext]
+ivy.deliver.ivy.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
+ivy.publish.src.artifacts.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
+
+ivy.report.output.pattern = [organisation]-[module]-[conf].[ext]
+
+ivy.buildlist.ivyfilepath = ivy.xml
+
+ivy.checksums=sha1,md5
+</code>
+<em>For the latest version of these properties, you can check the <a href="http://svn.jayasoft.org/projects/tools/ivy/src/java/fr/jayasoft/ivy/ivy.properties">svn version</a>.</em>
+
+<h1>Ivy tasks attributes : generalities</h1>
+Some tasks attributes values may be given through different places. The three possible places are :
+<ol>
+<li>task attribute</li>
+<li>ivy instance</li>
+<li>project property</li>
+</ol>
+The places are queried in this order, so anything set in task attribute will overwrite what would have been found in ivy instance, for example.
+
+The ivy instance considered here is an instance of the class Ivy, which is setup by a call to the configure task, and then reused for other tasks. Because most of the tasks need an ivy instance, they first check if one is available (i.e. configure has been called), and if none is available, then a default configure is called and the resulting ivy instance is used in the remaining tasks (unless another configure is called).
+
+It isn't generally necessary to understand this, but it can lead to some issues if you forget to call configure before another task and if the configure step was required in your environment.
+
+<h1>Usual cycle of main tasks</h1>
+<center><img src="/misc/ivy/images/main-tasks.png" /></center>
+<h1>Example</h1>
+Here is a more complete example of build file using ivy:
+
+<code type="xml">
+<project xmlns:ivy="antlib:fr.jayasoft.ivy.ant" name="sample" default="resolve">
+
+    <target name="resolve">
+        <ivy:configure file="../ivyconf.xml" />
+        
+        <ivy:resolve file="my-ivy.xml" conf="default, myconf" />
+        
+    </target>
+    
+    <target name="retrieve-default" depends="resolve">
+        <ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default" />
+    </target>
+
+    <target name="retrieve-myconf" depends="resolve">
+        <ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf" />
+    </target>
+
+    <target name="retrieve-all" depends="resolve">
+        <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" />
+    </target>
+
+    <target name="deliver" depends="retrieve-all">
+        <ivy:deliver deliverpattern="distrib/[artifact]-[revision].[ext]" pubrevision="1.1b4" pubdate="20050115123254" status="milestone" />
+    </target>
+
+    <target name="publish" depends="deliver">
+        <ivy:publish resolver="internal" artifactspattern="distrib/[artifact]-[revision].[ext]" pubrevision="1.1b4" />
+    </target>
+</project>
+</code>
+
+All ivy tasks are documented in the following pages.
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/appendix.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/appendix.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/appendix.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/appendix.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,13 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<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 section is the home of a bunch of appendixes to ivy main documentation.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/bestpractices.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/bestpractices.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/bestpractices.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/bestpractices.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,87 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 1};</script>	
+	<script type="text/javascript" src="../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+Here are some recommendations and best practices we have gathered throughout our experience and consultancies with our customers.
+
+<h1>Add module descriptors for all your modules</h1>
+In Ivy world, module descriptors are ivy files, which are basically simple xml files describing both what the module produce as artifact and its dependencies.
+
+It is a good practice to write or download module descriptors for all the modules involved in your development, even for your third party dependencies, and even if they don't provide themselves such module descriptors.
+
+First it will seem like an extra work, and require time. But when you will have several modules using the same third party library, and than you will only need to add one line to your ivy file to get this library and all its own dependencies that you really need (if you have good module descriptors in your repository, especially with the use of module <a href="../doc/concept#configurations.html">configurations</a>). It will also be very helpful when you want to upgrade a dependency. One single change in your module ivy file and you will get the updated version with its updated (or not) dependencies.
+
+Therefore we recommend to add ivy files for all the modules in your repository, you can even enforce this rule by setting the allownomd attribute to false on your <a href="../doc/configuration/resolvers.html">resolvers</a>. Hence you shouldn't need to use the dependency artifact inclusion/exclusion/specification feature of Ivy, which should only be used in very specific cases.
+
+<h1>Use your own enterprise repository</h1>
+This is usually not a valid recommendation for open source projects, but for the enterprise world we strongly suggest to avoid relying on a public repository like maven ibiblio or ivyrep. Why? Well, there are a couple of reasons:
+<ul>
+<li>control</li> The main problem with this kind of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fixed it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hide the one on the public repository, but this makes repository browsing and maintenance cumbersome. 
+Even more problematic is the possible updates of the repository. We know that versions published in such repositories should be stable and not be updated, but we also frequently see that a module descriptor is buggy, or an artifact corrupted. We even see sometimes a new version published with the same name as the preceding one because the previous one was simply badly packaged. This can occur even to the best, it occured to us with Ivy 1.2 :-) But then we decided to publish the new version with a different name, 1.2a. But if the repository manager allow such updates, this means that what worked before can break. It can thus break your build reproducibility.
+<li>reliability</li> Ibiblio maven repository is not particularly well known for its reliability (we often experience major slow down or even complete break of the site), and ivyrep is only supported by a small company (yes we are only a small company!). So slow down and site hang occurs also. And if the repository you rely on is down, this can cause major slow down in your development or release process.
+<li>accuracy</li> a public repository usually contains much more than what you actually need (except maybe ivyrep which certainly features much less than what you need :-)). Is it a problem? We think so. We think that in an enterprise environment the libraries you use should step through some kind of validation process before being used in every projects of your company. And what better way to do so? Setup an enterprise repository with only the libraries you actually want to use. This will not only ensure a better quality of your application dependencies, but help to have the same versions everywhere, and even help when declaring your module dependencies, if you use a tool like IvyDE, the code completion will only show relevant information about your repository, with only the libraries you actually want to see.
+</ul>
+Note that it's not because you use an enterprise repository that you have to build it entirely by hand. Ivy features an [ivy:ant:install] task which can be used to install modules from a repository to another one, so it can be used to selectively install modules from a public repository to your enterprise repository, where you will then be able to ensure control, reliability and accuracy.
+
+<h1>Always use patterns with at least organisation and module</h1>
+Ivy is very flexible and can accomodate a lot of existing repositories, using the concept of <a href="../doc/concept#pattern.html">patterns</a>. But if your repository doesn't exist yet, we strongly recommend to always use the organisation and the module name in your pattern, even for private repository where you put only your own modules (which all the same organisation). Why? Because Ivy listing feature rely on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like [ivy:ant:install] or [ivy:ant:rereport].
+
+<h1>Public ivyconf.xml with public repositories</h1>
+If you create a public repository, provide an url to corresponding <a href="../doc/configuration.html">ivyconf.xml</a>. It's pretty easy to do, and if someone want to leverage your repository, he will just have to call [ivy:ant:configure] with the url of your ivyconf.xml, or <a href="../doc/configuration/include.html">include</a> it in its own configuration file, which makes it really easy to combine several public repositories.
+
+<h1>Dealing with integration versions</h1>
+Very often especially when working in a team or with several modules, you will need to rely on intermediate, non finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework. 
+
+If you follow the continuous integration paradigm across modules, these integration versions can be produced by a continuous integration server, very frequently.
+
+So, how can you deal with these, possibly numerous, integration versions?
+
+There are basically two ways to deal with them, both ways being supported by Ivy:
+<ul>
+<li>use a naming convention like a special suffix</li> the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but check the date of the version on the repository and see if it hass changed. In Ivy this is supported using the <a href="../doc/ivyfile/dependency.html">changing attribute</a> on a dependency or by configuring the <a href="../doc/configuration/resolvers.html">changing pattern</a> to use for all your modules.
+<li>create automatically a new version for each</li> in this case you use either a build number or a timestamp to publish each new integration version with a new version name. Then you can use one of the numerous ways in Ivy to <a href="../doc/ivyfile/dependency.html">express a version constraint</a>. Usually selecting the very latest one (using 'latest.integration' as version constraint) is enough.
+</ul>
+
+So, which way is the best? As often, it depends on your context, and if one of the two was really bad it wouldn't be supported in Ivy :-)
+
+But usually we recommend to use the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make <b>all</b> your builds reproducible, even integration one. And this is interesting because it enables, with some work in your build system, to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release. 
+
+Imagine you have a customer which comes on a monday morning and asks your latest version of your software, for testing or demonstration purpose. Obviously he needs it for the afternoon :-) Now if you have a continuous integration process and a good tracking of your changes and your artifacts, it may occur that you are actually able to fulfill his request without needing the use of a dolorean to give you some more time :-) But it may occur also that your latest version stable enough to be used for the purpose of the customer was actually built a few days ago, because the very latest just break a feature or introduce a new one you don't want to deliver. In this case, you can deliver this 'stable' integration build if you want, but be sure that a few days, or weeks, or even months later, the customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we all know how they are :-)
+
+So, with a build promotion feature of any build in your repository, the solution would be pretty easy: when the customer ask for the version, you not only deliver the integration build, but you also promote it to a milestone status, for example. this promotion indicates that you should keep track of this version in a long period, to be able to come back to it and create a branch if needed.
+
+Unfortunately Ivy does not by its own allow to have such reproducible builds out of the box, simply because Ivy is a dependency manager, not a build tool. But if you publish only versions with a distinct name and use Ivy features like versions constraint replacement during the publication or recursive delivery of modules, it can really help.
+
+On the other hand, the main drawback of this solution is that it can produce a lot of intermediate versions, and  you will have to run some cleaning scripts in your repository unless your company name starts with a G and ends with oogle :-)
+
+<h1>Inlining dependencies or not?</h1>
+With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This pratice is called inlining. But what is it good for, and when should it be avoided?
+
+Putting ivy dependencies in a separate file has the following advantages:
+<ul>
+<li>separate revision cycle</li> if your dependencies may change more often than your build, it's a good idea to separate the two, to isolate the two concepts: describing how to build / describing your project dependencies
+<li>possibility to publish</li> if you describe dependencies of a module which can itself be reused, you will ant to publish it to a repository. In this case the publication is only possible if you have a separate ivy file
+<li>more flexible</li> inline dependencies can only be used to express one dependency and only one. An ivy file can be used to express much more complex dependencies
+</ul>
+On the other hand, using inline dependencies is very useful when:
+<ul>
+<li>you want to use a custom task in your ant build</a> Without ivy you usually either copy the custom task jar in ant lib, which requires maintenance of your workstation installation, or use a manual copy or download and a taskdef with the appropriate classpath, which is better. But if you have several custom tasks, or if they have themselves dependencies, it can become cumbersome. Using Ivy with an inline dependency is an elegant way to solve this problem.
+<li>you want to easily deploy an application</li> If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybee packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of <b>any</b> version of your application available in your repository!
+</ul>
+<h1>Hire an expert</h1>
+Build and dependency management is often considered with a too low level priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money saving in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured. 
+
+Therefore hiring a build and dependency expert to analyse and improve your build and release system is most of the time a very good choice (especially if you choose the <a href="./services">right one</a> :-))
+
+<h1>Feedback</h1>
+These best practices are the reflect of our own experience, but we do not pretend to own the unique truth about dependency management or even Ivy use.
+
+So feel free to comment on this page to add your own experience feedback, suggestions or opinion.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/concept.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/concept.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/concept.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/concept.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,217 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 1};</script>	
+	<script type="text/javascript" src="../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<h1>Dependency Resolver</h1>
+A dependency resolver is a pluggable class in ivy which is used to:
+<ul>
+<li>find dependencies ivy files</li>
+<li>download dependencies artifacts</li>
+</ul>
+The notion of artifact "downloading" is large: artifact can be on a web site, or on the local file system of your machine. The download is thus the fact to bring a file from a repository to ivy cache.
+
+Moreover, the fact that it is the responsibility of the resolver to find ivy files and download artifacts help to implement various resolving strategies.
+
+As you see, a dependency resolver can be thought as a class responsible of describing a repository.
+
+If you want to see which resolvers are available in ivy, you can go to the corresponding <a href="../doc/configuration/resolvers.html">configuration section</a>
+
+<h1><a name="configurations">Module configurations explained</a></h1>
+Module configurations are described in the terminology page as <em>a way to use or construct a module</em>. Configurations being a central part of Ivy, they need more explanations as a concept.
+<br/>
+When you define a way to use or construct a module, you are able to define which artifacts are published by this module in this configuration, and you are also able to define which dependencies are needed in this configuration.
+
+Moreover, because dependencies in ivy are expressed on modules and not on artifacts, it is important to be able to define which configurations of the dependency are required in the configuration you define of your module. That's what is called <strong>configuration mapping</strong>.
+
+If you use only simple modules and do not want to worry about configurations, you don't have to worry about them. They're still there under the hood, cause ivy can't work without configuration. But most of the time if you declare nothing, ivy assumes that the artifacts of your module are published in all configurations, and that all the dependencies configurations are required in all configurations. And it works in simple cases. But whenever you want to separate things within a module, or get more control over things published and got through dependencies resolution, configuration may answer most of your needs.
+
+For details on how to declare your module configurations, how declare in which configuration your artifacts are published, and how to declare configuration mapping, please refer to <a href="../doc/ivyfile.html">ivy file documentation</a>. The <a href="../doc/tutorial/conf.html">configurations tutorial</a> is also a good place to go to learn more about this concept.
+
+<h1>Variables</h1>
+During configuration, ivy allows to define what are called ivy variables. Ivy variables can be seen as ant properties, and are used in a very similar way. In particular, you use a properties tag in the configuration file to load a properties file containing ivy variables and their values.
+
+But the main differences between ant properties and ivy variables are that ivy variables can be overriden, whereas ant 
+properties can't, and that they are defined in separate environment.
+
+Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant). 
+This means that if you define an ant property after the call to configure, it will not be available as an ivy variable.
+On the other hand, ivy variables are NOT exported to ant, thus if you define ivy variables in ivy, do not try to use them as ant properties.
+
+To use ivy variables, you just have to follow that same syntax as for ant properties:
+${<i>variablename</i>}
+where <i>variablename</i> is the name of the variable.
+
+Finally, it's also important to be aware of the time of substitution of variables. This substitution is done as soon as possible. This means that when ivy encounter a reference to a variable, it tries to substitute it if such a variable is defined. Consequently, <strong>any later modification of the variable will not alter the value already substituted</strong>.
+
+Moreover, in an ant environment, a bunch of variables are going to be set by default via the ant property file loading mechanism (in fact they are first loaded as ant properties and then imported as ivy variables, see <a href="../doc/use.html"></a>), and even in the ant properties themselves there is going to be eager substitution on loading, effectively making it impossible to override some variable purely via the ivyconf.properties file. Some variables will really only be able to be overriden via ant properties because of this.
+
+Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens. 
+See Patterns chapter below to see what pattern tokens are.
+<h1>Patterns</h1>
+
+Ivy patterns are used in many dependency resolvers and ivy tasks, and are a simple way to structure the way ivy works.
+
+First let's give an example. You can for instance configure the file system dependency resolver by giving it
+a pattern to find artifacts. This pattern can be like this:
+myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
+
+This pattern indicates that the repository we use is in a directory called myrepository. 
+
+In this directory we have directories having for name the name of the organisation of the module we look for. 
+Then we have a directory per module, each having for name the name of the module.
+Then in module directories we find a directory per artifact type (jars, wars, ivys, ...), in which we find artifacts named by the artifact id, followed by an hyphen, then the revision, a dot, and the artifact extension.
+Not too difficult to understand, isn't it ? That's it, you have understood the pattern concept !
+
+To give a bit more explanation, a pattern is composed of tokens, which are replaced by actual values when evaluated for a particular artifact or module. Those tokens are different from variables because they are replaced differently for each artifact, whereas variables are usually given the same value.
+
+You can mix variables and tokens in a pattern:
+${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]<br/><br/>
+
+The tokens available depends on where the pattern is used (will it be evaluated with artifacts or modules, for instance).
+But here are all the tokens currently available:
+<ul>
+<li>[organisation]</li> the organisation name
+<li>[module]</li> the module name
+<li>[branch]</li> the branch name
+<li>[revision]</li> the revision name
+<li>[artifact]</li> the artifact name (or id)
+<li>[type]</li> the artifact type
+<li>[ext]</li> the artifact file extension
+<li>[conf]</li> the configuration name
+<li>[originalname] <span class="since">(since 1.4)</span></li> the original artifact name (including the extension)
+</ul>
+
+Difference between type and extension are explained in ivy file documentation.
+
+<span class="since">since 1.2</span> [organization] can be used instead of [organisation].
+
+<span class="since">since 1.3</span> Optinal parts can be used in patterns.
+This let the possibility to avoid some input when a token is not defined, instead of having only the token as blank. Parenthesis are used to delimit the optional part, and only one token can be found inside the parenthesis.
+So if you surround a token with '(' and ')', any other text which is between the parenthesis will be ignored if the token has no value.
+
+For instance, suppose the pattern: "abc(def[type]ghi)"
+type = "jar" -> the substituted pattern: abcdefjarghi
+type = null or "" -> the substitued pattern: abc
+
+A more real life example:
+The pattern <code>[artifact](-[revision]).[ext]</code> let you accept both myartifact-1.0.jar when a revision is set, and myartifact.jar (instead of myartifact-.jar) when no revision is set
+This is particularly useful when you need to keep control on artifact names.
+
+<span class="since">since 1.4</span> Extra attributes can be used as any other token in the patterns.
+
+<h1><a name="latest">Latest Strategy</a></h1>
+Ivy often needs to know which revision between two has to be considered the "latest". For knowing that, it uses the concept of latest strategy. Indeed, there are several way to consider a revision to be the latest.
+You can choose an existing one or plug your own.
+
+But before knowing which revision is the latest, ivy needs to be able to consider several revision of a module. Thus ivy has to get a list of files in a directory, and it uses the dependency resolver for that. So check if the dependency resolver you use is compatible with latest revisions before wondering why ivy do not manage to get your latest revision.
+
+Finally, In order to get several revisions of a module, most of the time you need to use the [revision] token in your pattern, so that ivy gets all the files which match the pattern whatever the revision is. It's only then that the latest strategy is used to determine which of this revisions is the latest one.
+
+Ivy has three built-in latest strategies:
+<ul>
+<li>latest-time</li> it compares the revisions date to know which is the latest. While this is often a good strategy in terms of pertinence, it has the drawback to be costful to compute with distant repositories. If you use ivyrep, for example, ivy has to ask the http server what is the date of each ivy file before knowing which is the latest.
+<li>latest-revision</li> it compares the revisions as string, using an algorithm close to the one used in the php version_compare function.
+This algorithm takes into account special meaning of some text. For instance, with this strategy, 1.0-dev1 is considered before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
+<li>latest-lexico</li>: it compares the revisions as string, using lexicographic order (the one used by java string comparison).
+</ul>
+
+See also how to configure new latest strategies <a href="../doc/configuration/latest-strategies.html">here</a>.
+
+<h1><a name="conflict">Conflict Manager</a></h1>
+A conflict manager is able to select, among a list of module revisions in conflict, a list of revisions to keep.
+Yes, it can selects a list of revision, even if most conflicts manager select only one revision.
+But in some cases you will need to keep several revisions, and load in separate class loaders, for example.
+
+A list of revisions is said to be in conflict if they correspond to the same module, i.e. the same organisation/module name couple.
+
+The list of available conflict managers is available on the <a href="../doc/configuration/conflict-managers.html">conflict manager configuration page</a>.
+
+To have more details on how to setup your conflict managers by module, see <a href="../doc/ivyfile/conflicts.html">conflicts</a> section in ivy file reference.
+
+<h1><a name="matcher">Pattern matcher</a></h1>
+<span class="since">since 1.3</span>
+At several places Ivy let uses pattern to match a set of objects. For instance, you can exclude several modules at once when declaring a dependency by using a pattern matching all the modules to exclude.
+
+Ivy uses pluggable pattern matcher to match those object names. 3 are defined by default:
+<ul>
+<li>exact</li>This matcher matches only string when they are equal to the pattern one
+<li>regexp</li>This matcher let you use regular expression as supported by the Pattern class of java 1.4 or greater
+<li>glob</li>This matcher let you use unix like glob matcher, i.e. where the only meta characters are * which matches any sequence of characters and ? which matches exactly one character. Note that this matcher is available only with jakarta oro 2.0.8 in your classpath.
+</ul>
+Note also that with any matcher the character '*' has the special meaning of matching anything. This is particularly useful with default values which do not depend on the matcher.
+
+<h1><a name="extra">Extra attributes</a></h1>
+<span class="since">since 1.4</span>
+Several tags in ivy xml files are extensible with what is called extra attributes. 
+The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns for example.
+
+Example:
+Here is an ivy file with the attribute 'color' set to blue:
+<code type="xml">
+<ivy-module version="1.4">
+	<info organisation="jayasoft"
+	       module="foo"
+	       color="blue"
+	       status="integration"
+	       revision="1.59"
+	/>
+</ivy-module>
+</code>
+Then you can use the extra attribute when you declare a dependency on foo:
+<code>
+<dependency org="jayasoft" name="foo" color="blue" rev="1.5+" />
+</code>
+And you can define your repository pattern as:
+<code>
+${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
+</code>
+
+Note that in order to use extra attributes, you will need to disable ivy file validation, since your files won't fulffill anymore the official ivy xsd. See the <a href="../doc/configuration/conf.html">configuration doc page</a> to see how to disable validation.
+<h1><a name="checksum">Checksums</a></h1>
+<span class="since">since 1.4</span>
+Ivy allow to use checksums, also known as digester, to verify the correctness of a downloaded file.
+
+For the moment Ivy supports md5 and sha1 algorithm.
+
+The configuration of using md5 and/or sha1 can be done globally or by dependency resolver.
+Globally, use the ivy.checksums variable to list the check to be done (only md5 and sha1 are supported).
+On each resolver you can use the checksums attribute to override the global setting.
+
+The setting is a comma separated list of checksum algorithm to use.
+During checking (at download time), the first checksum found is checked, and that's all. This means that if you have a "sha1, md5" setting, then if ivy finds a sha1 file, it will compare the downloaded file sha1 against this sha1, and if the comparison is ok, it will assume the file is ok. If no sha1 file is found, it will look for a md5 file. If none is found no checking is done.
+During publish, all listed checksum algorithms are computed and uploaded.
+
+By default checksum algorithms are "sha1, md5".
+
+If you want to change this default, you can set the variable ivy.checksums. Hence to disable checksum validation you just have to set ivy.checksums to "".
+
+<h1><a name="event">Events and Triggers</a></h1>
+<span class="since">since 1.4</span>
+When Ivy performs the dependency resolution and some other tasks, it fires events before and after the most important steps. You can listen to these events using Ivy API, or you can even register a trigger to perform a particular action when a particular event occur.
+
+This is a particularly powerful and flexible feature which allow for example to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accuratly, and so on.
+
+For more details about event and triggers, see the <a href="../doc/conf/triggers.html">triggers</a> documentation page in the configuration section of this documentation.
+
+<h1><a name="circular">Circular Dependencies</a></h1>
+<span class="since">since 1.4</span>
+Circular dependencies can be either direct or indirect. For instance, if A depends on A it's a circular dependency, and if A depends on B which itself depends on A, this is also a circular dependency.
+
+Prior to Ivy 1.4 circular dependencies where causing a failure in Ivy. As of Ivy 1.4, the behaviour of Ivy when it finds a circular dependency is configurable through a circular dependency strategy.
+
+3 built-in strategies are available:
+<ul>
+<li>ignore</li> circular dependencies are only signaled in verbose messages
+<li>warn</li> same as ignore, except that they are signaled as warning (default)
+<li>error</li> halt the dependency resolution when a circular dependency is found. 
+</ul>
+
+See the <a href="../doc/configuration/conf.html">configuration page</a> to see how to configure the circular dependency strategy you want to use.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/conf/triggers.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/conf/triggers.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/conf/triggers.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/conf/triggers.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,199 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 2};</script>	
+	<script type="text/javascript" src="../../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<b>Tag:</b> triggers
+<span class="since">since 1.4</span>
+
+Defines a list of triggers to activate on some Ivy events.
+
+A trigger is an action which is performed whenever a particular event occurs.
+Ivy supports two type of triggers out of the box: ant-call and ant-build. The first calls a target in the same build as the original one whenever a particular event occurs, the second call an ant build which may be in another ant build script.
+
+If you want to use a different trigger, you can <a href="../../doc/extend.html">implement your own</a>.
+
+The event available in Ivy are the following ones:
+<table class="ivy-children">
+<thead>
+    <tr><th>Name</th><th>Attributes</th><th>Description</th></tr>
+</thead>
+<tbody>
+    <tr><td>pre-resolve</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the module for which the dependencies will be resolved
+            <li>module</li>the name of the module for which the dependencies will be resolved
+            <li>revision</li>the revision of the module for which the dependencies will be resolved
+            <li>conf</li>comma separated list of configurations which will be resolved
+          </ul>
+        </td>
+        <td>Fired before a module dependencies will be resolved</td>
+    </tr>
+    <tr><td>pre-resolve-dependency</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the dependency resolved
+            <li>module</li>the name of the dependency resolved
+            <li>revision</li>the revision asked for the dependency
+            <li>resolver</li>the name of the resolver used to resolve the dependency
+          </ul>
+        </td>
+        <td>Fired before each dependency is resolved in a single resolve call</td>
+    </tr>
+    <tr><td>post-resolve-dependency</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the dependency resolved
+            <li>module</li>the name of the dependency resolved
+            <li>revision</li>the revision of the dependency resolved, or the revision asked if the resolution was not successful
+            <li>resolved</li>true if the resolution was successful, false otherwise
+            <li>resolver</li>the name of the resolver used to resolve the dependency
+          </ul>
+        </td>
+        <td>Fired after each dependency resolved in a single resolve call</td>
+    </tr>
+    <tr><td>post-resolve</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the module for which the dependencies have been resolved
+            <li>module</li>the name of the module for which the dependencies have been resolved
+            <li>revision</li>the revision of the module for which the dependencies have been resolved
+            <li>conf</li>comma separated list of configurations resolved
+          </ul>
+        </td>
+        <td>Fired after a module dependencies has been resolved</td>
+    </tr>
+    <tr><td>pre-download-artifact</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the artifact which is about to be downloaded
+            <li>module</li>the name of the module of the artifact which is about to be downloaded
+            <li>revision</li>the revision of the the artifact which is about to be downloaded
+            <li>artifact</li>the name of the the artifact which is about to be downloaded
+            <li>type</li>the type of the the artifact which is about to be downloaded
+            <li>ext</li>the extension of the the artifact which is about to be downloaded
+            <li>resolver</li>the name of the resolver used to download the artifact
+            <li>origin</li>the origin location from which it will be downloaded
+            <li>local</li>true if it's a local artifact, false otherwise
+          </ul>
+        </td>
+        <td>Fired before an artifact is downloaded from a repository to the cache</td>
+    </tr>
+    <tr><td>post-download-artifact</td>
+        <td>
+          <ul>
+            <li>organisation</li>the organisation of the artifact which was just downloaded
+            <li>module</li>the name of the module of the artifact which was just downloaded
+            <li>revision</li>the revision of the the artifact which was just downloaded
+            <li>artifact</li>the name of the the artifact which was just downloaded
+            <li>type</li>the type of the the artifact which was just downloaded
+            <li>ext</li>the extension of the the artifact which was just downloaded
+            <li>resolver</li>the name of the resolver used to download the artifact
+            <li>origin</li>the origin location from which it was downloaded
+            <li>local</li>true if it's a local artifact, false otherwise
+            <li>size</li>the size in bytes of the downloaded artifact
+            <li>file</li>the file to which it has been downloaded
+          </ul>
+        </td>
+        <td>Fired after an artifact has been downloaded from a repository to the cache</td>
+    </tr>
+</tbody>
+</table>
+
+
+The child tag used for the dependency resolver must be equal to a name of a trigger type (either built-in or added with the typedef tag).
+
+<h1>Child elements</h1>
+<table class="ivy-children">
+<thead>
+    <tr><th class="ivy-chld">Element</th><th class="ivy-chld-desc">Description</th><th class="ivy-chld-card">Cardinality</th></tr>
+</thead>
+<tbody>
+    <tr><td>any trigger</td><td>adds a trigger to the list of registered triggers</td>
+        <td>1..n</td></tr>
+</tbody>
+</table>
+
+<h1>Built-in Triggers</h1>
+Ivy comes with two built-in triggers: 
+
+<table class="ivy-attributes">
+<thead>
+    <tr><th>Name</th><th>Description</th></tr>
+</thead>
+<tbody>
+<tr><td>ant-build<a href="../../doc/trigger/ant-build.html"></a></td><td>Triggers an ant build.</td></tr>
+<tr><td>ant-call<a href="../../doc/trigger/ant-call.html"></a></td><td>Calls a target in the current ant build.</td></tr>
+</tbody>
+</table>
+
+
+<h1><a name="common">Common attributes</a></h1>
+All triggers share some common attributes detailed here.
+
+Among these attributes, you will find how to select when the trigger should be performed. You have to provide an event name, which is simple, but you can also use a filter expression. The syntax for this expression is very simple and limited: 
+you can use the = operator to compare an attribute (left operande) with a value (right operande).
+you can use AND OR NOT as boolean operators
+you cannot use parenthesis to change the precedence
+
+<table class="ivy-attributes">
+<thead>
+    <tr><th class="ivy-att">Attribute</th><th class="ivy-att-desc">Description</th><th class="ivy-att-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>name</td><td>the name of the trigger for identification purpose only</td>
+        <td>Yes</td>
+    </tr>
+    <tr><td>event</td><td>the name of the event on which the trigger should be performed</td>
+        <td>Yes</td>
+    </tr>
+    <tr><td>filter</td><td>a filter expression used to restrict when the trigger should be performed</td>
+        <td>No, defaults to no filter</td>
+    </tr>
+</tbody>
+</table>
+
+<h1>Examples</h1>
+<code type="xml">
+<triggers>
+    <ant-build antfile="${ivy.conf.dir}/[module]/build.xml" target="publish"
+           event="pre-resolve-dependency" filter="revision=latest.integration"/>
+</triggers>
+</code>
+Triggers an ant build of the ant file ${ivy.conf.dir}/[module]/build.xml (where [module] is replaced by the name of the dependency resolved) with the target "publish", just before resolving a dependency with a latest.integration revision.
+<hr/>
+<code type="xml">
+<triggers>
+    <ant-call target="unzip" prefix="dep"
+          event="post-download-artifact" filter="type=zip AND status=successful"/>
+</triggers>
+</code>
+Triggers an ant call of the target unzip just after downloading a zip artifact, prefixing all parameters to the target with 'dep'.
+Here is how the target can look like:
+<code type="xml">
+<target name="unzip">
+     <echo>
+        unzipping artifact: 
+        organisation=${dep.organisation} 
+        module=${dep.module} 
+        revision=${dep.revision}
+        artifact=${dep.artifact}
+        type=${dep.type}
+        ext=${dep.ext}
+        origin=${dep.origin}
+        local=${dep.local}
+        size=${dep.size}
+        file=${dep.file}
+     </echo>
+     <mkdir dir="${basedir}/out"/>
+     <unzip src="${dep.file}" dest="${basedir}/out"/>
+</target>
+</code>
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/configuration.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/configuration.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/configuration.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/configuration.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,134 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<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 order to work as you want, ivy need some configuration. Actually, ivy can work with no configuration at all, see the <a href="../doc/tutorial/defaultconf.html">default configuration documentation</a> for details about that. But ivy is able 
+to work in very different contexts. You just have to configure it properly.
+
+Configuration is done through an xml file, usually called ivyconf.xml. To configure ivy from ant, you just have to call the configure task and pass it the path to your configuration file (see <a href="../doc/use/configure.html">configure</a> task documentation for details).
+
+Here is an example of configuration file :
+<code type="xml">
+<ivyconf>
+        <properties file="${ivy.conf.dir}/ivyconf-file.properties" />
+        <conf defaultCache="${cache.dir}" defaultResolver="ibiblio" checkUpToDate="false" />
+        <resolvers>
+                <ibiblio name="ibiblio" />
+                <filesystem name="internal">
+                        <ivy pattern="${repository.dir}/[module]/ivy-[revision].xml" />
+                        <artifact pattern="${repository.dir}/[module]/[artifact]-[revision].[ext]" />
+                </filesystem>
+        </resolvers>
+        <modules>
+                <module organisation="jayasoft" name=".*" resolver="internal" />
+        </modules>
+</ivyconf>
+</code>
+</div>
+<br/>
+Mainly, the configuration enables to configure the default cache directory used by ivy and the dependency resolvers that it will use to resolve dependencies.
+<i>Note: To work, this configuration file needs a property file named ivyconf-file.properties in the same directory as the configuration file, with ivy variables you want in it.</i>
+
+Some useful variables are available in ivyconf files:
+<ul>
+<li>ivy.conf.dir</li> this variable references the directory in which the ivyconf itself is. This is available if the ivyconf has been loaded as a file. In case of an url, it takes the part before the last slash of the url, if any. If the url has no slash, then this variable is not set.
+<li>ivy.conf.file</li>the path of the ivyconf file itself, it has been loaded as a file only. If it has been loaded as an url, this variable is not set
+<li>ivy.conf.url</li>the url pointing to the ivyconf file. This is set both when it has been loaded as a file or an url
+</ul>
+
+<span class="since">since 1.4</span> Note that all <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#getProperties()">java system properties</a> are available as ivy variables in your configuration file.
+
+<h1>Configuration file structure</h1>
+
+The configuration file is structured in some parts and left other open. Indeed each resolver has its own 
+structure, thus it's not the configuration file itself which define the structure for the resolvers.
+
+<pre>
+ivyconf
+    <a href="../doc/configuration/property.html">property</a>
+    <a href="../doc/configuration/properties.html">properties</a>
+    <a href="../doc/configuration/conf.html">conf</a>
+    <a href="../doc/configuration/include.html">include</a>
+    <a href="../doc/configuration/classpath.html">classpath</a>
+    <a href="../doc/configuration/typedef.html">typedef</a>
+    <a href="../doc/configuration/latest-strategies.html">latest-strategies</a>
+    <a href="../doc/configuration/version-matchers.html">version-matchers</a>
+    <a href="../doc/configuration/triggers.html">triggers</a>
+    <a href="../doc/configuration/parsers.html">parsers</a>
+    <a href="../doc/configuration/conflict-managers.html">conflict-managers</a>
+    <a href="../doc/configuration/outputters.html">outputters</a>
+    <a href="../doc/configuration/namespaces.html">namespaces</a>
+        <a href="../doc/configuration/namespace.html">namespace</a>
+            <a href="../doc/configuration/namespace/rule.html">rule</a>
+                <a href="../doc/configuration/namespace/fromtosystem.html">fromsystem</a>
+                    <a href="../doc/configuration/namespace/src.html">src</a>
+                    <a href="../doc/configuration/namespace/dest.html">dest</a>
+                <a href="../doc/configuration/namespace/fromtosystem.html">tosystem</a>
+                    <a href="../doc/configuration/namespace/src.html">src</a>
+                    <a href="../doc/configuration/namespace/dest.html">dest</a>
+    <a href="../doc/configuration/macrodef.html">macrodef</a>
+        <a href="../doc/configuration/macrodef/attribute.html">attribute</a>
+        any resolver
+    <a href="../doc/configuration/resolvers.html">resolvers</a>
+        any resolver
+    <a href="../doc/configuration/modules.html">modules</a>
+        <a href="../doc/configuration/module.html">module</a>
+    <a href="../doc/configuration/statuses.html">statuses</a>
+        <a href="../doc/configuration/status.html">status</a>
+</pre>
+
+<h1>ivyconf</h1>
+<b>Tag:</b> ivyconf
+
+Root tag of any ivyconf file.
+<h2>Child elements</h2>
+<table class="ivy-children">
+<thead>
+    <tr><th class="ivy-chld">Element</th><th class="ivy-chld-desc">Description</th><th class="ivy-chld-card">Cardinality</th></tr>
+</thead>
+<tbody>
+    <tr><td><a href="../doc/configuration/property.html">property</a></td><td>set an ivy variable</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/properties.html">properties</a></td><td>loads a properties file as ivy variables</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/conf.html">conf</a></td><td>configures ivy with some defaults</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/include.html">include</a></td><td>includes another ivyconf file</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/classpath.html">classpath</a></td><td>add a location in the classpath used to load plugins</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/typedef.html">typedef</a></td><td>defines new types in ivy</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/latest-strategies.html">latest-strategies</a></td><td>defines latest strategies</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/parsers.html">parsers</a></td><td>defines module descriptor parsers</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/version-matchers.html">version-matchers</a></td><td>defines new version matchers</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/triggers.html">triggers</a></td><td>register triggers on ivy events</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/namespaces.html">namespaces</a></td><td>defines new namespaces</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/macrodef.html">macrodef</a></td><td>defines a new macro resolver</td>
+        <td>0..n</td></tr>
+    <tr><td><a href="../doc/configuration/resolvers.html">resolvers</a></td><td>defines dependency resolvers</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/conflict-managers.html">conflict-managers</a></td><td>defines conflicts managers</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/modules.html">modules</a></td><td>defines rules between modules and dependency resolvers</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/outputters.html">outputters</a></td><td>defines the list of available report outputters</td>
+        <td>0..1</td></tr>
+    <tr><td><a href="../doc/configuration/statuses.html">statuses</a></td><td>defines the list of available statuses</td>
+        <td>0..1</td></tr>
+</tbody>
+</table>
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/configuration/classpath.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/configuration/classpath.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/configuration/classpath.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/configuration/classpath.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,53 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 2};</script>	
+	<script type="text/javascript" src="../../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<b>Tag:</b> classpath
+
+Includes a jar in the classpath used to load plugins. <span class="since">since 1.4</span>
+
+This let you add ivy plugins without relying on ant classpath for instance, easing therefore the use of ivy in multiple execution environment (ant, standalone, IDE plugins, ...).
+
+<h1>Attributes</h1>
+<table class="ivy-attributes">
+<thead>
+    <tr><th class="ivy-att">Attribute</th><th class="ivy-att-desc">Description</th><th class="ivy-att-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>url</td><td>the url of a jar to add to the classpath</td>
+        <td>Yes, unless file is specified</td></tr>
+    <tr><td>file</td><td>a jar to add to the classpath</td>
+        <td>Yes, unless url is specified</td></tr>
+</tbody>
+</table>
+<h1>Examples</h1>
+<code type="xml">
+<ivyconf>
+  <classpath file="${ivy.conf.dir}/custom-resolver.jar"/>
+  <typedef name="custom" classname="fr.jayasoft.ivy.resolver.CustomResolver"/>
+  <resolvers>
+    <custom name="custom"/>
+  </resolvers>
+</ivyconf>
+</code>
+Adds custom-resolver.jar found in the same directory as the ivyconf.xml file itself to the classpath, then define a custom resolver and use it.
+
+<hr/>
+<code type="xml">
+<ivyconf>
+  <classpath url="http://www.myserver.com/ivy/custom-resolver.jar"/>
+  <typedef name="custom" classname="fr.jayasoft.ivy.resolver.CustomResolver"/>
+  <resolvers>
+    <custom name="custom"/>
+  </resolvers>
+</ivyconf>
+</code>
+Same as above, but find the jar on a web server.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/configuration/conf.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/configuration/conf.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/configuration/conf.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/configuration/conf.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,64 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 2};</script>	
+	<script type="text/javascript" src="../../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<b>Tag:</b> conf
+
+Configures some important ivy info: default cache, default resolver, ...
+
+<i>Note that this is not related at all with conf found in ivy files. This tag is only used to setup ivy.</i>
+
+Default cache is used whenever a cache is not provided. It usually points to a directory in your filesystem. <strong>This should not point to a directory used as a repository!</strong>
+
+Default resolver is used whenever nothing elese is configured in the modules section of the configuration file. It should give the name of a dependency resolver defined in the resolvers section of the configuration file.
+
+Default latest strategy and conflict manager can also be configured here.
+
+validate indicates if ivy files should generally be validate against xsd or not. This setting is only a default value, and can be overriden :
+1) in ant tasks
+2) in resolvers
+So if there is a setting in the resolver, it always win against all other settings.
+
+checkUpToDate indicates to ivy if it must check date of artifacts before retrieving them (i.e. copying them from
+cache to another place in your filesystem). Usually it is a good thing to check date to avoid unnecessary copy, even if it's most of the time a local copy.
+
+cacheIvyPattern and cacheArtifactPattern are used to configure the way ivy stores ivy files and artifacts in the cache. Usually you do not have to change this, unless you want to use the cache directly from another tool, which is not recommended.
+<h1>Attributes</h1>
+<table class="ivy-attributes">
+<thead>
+    <tr><th class="ivy-att">Attribute</th><th class="ivy-att-desc">Description</th><th class="ivy-att-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>defaultCache</td><td>a path to a directory to use as default cache</td>
+        <td>No, defaults to .ivy/cache in user home</td></tr>
+    <tr><td>defaultResolver</td><td>the name of the default resolver to use</td>
+        <td>No, but all modules should be configured in the modules section if not provided</td></tr>
+    <tr><td>defaultLatestStrategy</td><td>the name of the default latest strategy to use</td>
+        <td>No, defaults to latest-revision</td></tr>
+    <tr><td>defaultConflictManager</td><td>the name of the default conflict manager to use</td>
+        <td>No, defaults to latest-revision</td></tr>
+    <tr><td>defaultBranch</td><td>the default branch to use for all modules, except if they have a <a href="../../doc/configuration/module.html"> module specific branch setting</a>. <span class="since">since 1.4</span></td>
+        <td>No, defaults to no default branch</td></tr>
+    <tr><td>circularDependencyStrategy</td><td>the name of the <a href="../../doc/concept#circular.html">circular dependency strategy</a> to use <span class="since">since 1.4</span></td>
+        <td>No, defaults to warn</td></tr>
+    <tr><td>validate</td><td>Indicates if ivy files should be validated against ivy.xsd or not.</td>
+        <td>No, defaults to true</td></tr>
+    <tr><td>checkUpToDate</td><td>Indicates if date should be checked before retrieving artifacts from cache</td>
+        <td>No, defaults to true</td></tr>
+    <tr><td>cacheIvyPattern</td><td>a pattern to indicate where ivy files should be put in cache</td>
+        <td>No, defaults to [organisation]/[module]/ivy-[revision].xml</td></tr>
+    <tr><td>cacheArtifactPattern</td><td>a pattern to indicate where artifact files should be put in cache</td>
+        <td>No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]</td></tr>
+    <tr><td>useRemoteConfig</td><td>true to configure ivyrep and ibiblio resolver from a remote configuration file (updated with changes in those repository structure if any) (<span class="since">since 1.2</span>)</td>
+        <td>No, defaults to false</td></tr>
+</tbody>
+</table>
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/configuration/conflict-managers.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/configuration/conflict-managers.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/configuration/conflict-managers.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/configuration/conflict-managers.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,46 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 2};</script>	
+	<script type="text/javascript" src="../../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<b>Tag:</b> conflict-managers
+
+Defines a list of <a href="../../doc/concept#conflict.html">conflicts managers</a> usable in ivy. Each conflict manager is identified by its name, given as an attribute.
+The child tag used for the conflict manager must be equal to a name of a conflict manager type (either built-in
+or added with the typedef tag).
+
+Here is a list of predefined conflicts managers (which do not require anything in the configuration file):
+<ul>
+<li>all</li> this conflicts manager resolve conflicts by selecting all revisions. Also called NoConflictManager, it does evict any module.
+<li>latest-time</li> this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
+<li>latest-revision</li> this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions.
+<li>strict</li> this conflict manager throws an exception (i.e. causes a build failure) whenever a conflict is found.
+</ul>
+The two "latest" conflict managers also take into account the force attribute of the dependencies.
+Indeed direct dependencies can declare a force attribute (see <a href="../../doc/ivyfile/dependency.html">dependency</a>), which indicates the the revision given in the direct dependency should be prefered over indirect dependencies.
+
+Here is a list of conflict manager types available, which can be used to define your own custom conflict managers:
+<ul>
+<li>latest-cm</li>The latest conflict manager uses a latest strategy to select the latest revision among several ones. Both latest-time and latest-revision conflict managers are based on this conflict manager type. It takes 'latest' as attribute to define which latest strategy should be used. Example:
+<code><latest-cm name="mylatest-conflict-manager" latest="my-latest-strategy"/></code>
+<li>regexp-cm</li>This conflict manager is based on a regular expression and throw an exception (i.e. causes a build failure) when a conflict is found with versions with different matching group. For instance if a conflict is found between 1.2.x and 1.3.y it will throw an exception if the regular exception is (.*)\.\d, because the matching group will match different string (1.2 and 1.3). 1.2.1 and 1.2.2 won't throw an exception with the same regular expression. The regular expression is set using the 'regexp' attribute. A 'ignoreNonMatching' attribute can also be set to simply warrn when a version is found which does not match the regular expression, instead of throwing an exception.
+</ul>
+
+<h3>Child elements</h3>
+<table class="ivy-children">
+<thead>
+    <tr><th class="ivy-chld">Element</th><th class="ivy-chld-desc">Description</th><th class="ivy-chld-card">Cardinality</th></tr>
+</thead>
+<tbody>
+    <tr><td>any conflict manager</td><td>adds a conflict manager to the list of available conflict managers</td>
+        <td>0..n</td></tr>
+</tbody>
+</table>
+
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>

Added: incubator/ivy/trunk/src/doc/xooki/doc/configuration/include.html
URL: http://svn.apache.org/viewvc/incubator/ivy/trunk/src/doc/xooki/doc/configuration/include.html?view=auto&rev=488342
==============================================================================
--- incubator/ivy/trunk/src/doc/xooki/doc/configuration/include.html (added)
+++ incubator/ivy/trunk/src/doc/xooki/doc/configuration/include.html Mon Dec 18 09:06:07 2006
@@ -0,0 +1,58 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<script type="text/javascript">var xookiConfig = {level: 2};</script>	
+	<script type="text/javascript" src="../../xooki/xooki.js"></script>
+</head>
+<body>
+	<textarea id="xooki-source">
+<b>Tag:</b> include
+
+Includes another ivyconf file as if it were part of this one. <span class="since">since 1.3</span>
+
+The included ivyconf file has to be a complete well formed ivyconf file, i.e. it does have to include the <code><ivyconf></code> tag.
+
+<h1>Attributes</h1>
+<table class="ivy-attributes">
+<thead>
+    <tr><th class="ivy-att">Attribute</th><th class="ivy-att-desc">Description</th><th class="ivy-att-req">Required</th></tr>
+</thead>
+<tbody>
+    <tr><td>file</td><td>a path to the ivyconf file to include</td>
+        <td>Yes</td></tr>
+</tbody>
+</table>
+<h1>Examples</h1>
+<code type="xml">
+<ivyconf>
+  <property name="myrepository" value="path/to/my/real/rep"/>
+  <conf defaultResolver="default"/>
+  <include file="path/to/ivyconf-default.xml"/>
+</ivyconf>
+</code>
+with ivyconf-default.xml:
+<code type="xml">
+<ivyconf>
+  <property name="myrepository" value="path/to/rep" overwrite="false"/>
+  <resolvers>
+    <ivyrep name="default" ivyroot="${myrepository}"/>
+  </resolvers>
+</ivyconf>
+</code>
+
+The included ivyconf defines a resolver named default, which is an ivyrep resolver, with its root configured as being the value of myrepository variable. This variable is given the value path/to/rep in the included file, but because the attribute overwrite is set to false, it will not overide the value given in the main ivyconf including this one, so the value used for myrepository will be path/to/my/real/rep.
+<hr/>
+<code type="xml">
+<ivyconf>
+  <include file="ivyconf-macro.xml"/>
+  <resolvers>
+    <mymacro name="includeworks" mymainrep="included/myrep" mysecondrep="included/secondrep"/>
+  </resolvers>
+</ivyconf> 
+</code>
+with ivyconf-macro.xml being the ivyconf example given on the <a href="../../doc/configuration/macrodef.html">macrodef documentation page</a>.
+This let reusing macro resolver easy.
+	</textarea>
+<script type="text/javascript">xooki.postProcess();</script>
+</body>
+</html>