You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by xa...@apache.org on 2007/03/19 13:14:33 UTC
svn commit: r519939 [1/4] - in /incubator/ivy/core/trunk: ./ doc/ doc/doc/
doc/doc/configuration/ doc/doc/tutorial/ doc/doc/tutorial/build-repository/
doc/doc/use/
Author: xavier
Date: Mon Mar 19 06:14:32 2007
New Revision: 519939
URL: http://svn.apache.org/viewvc?view=rev&rev=519939
Log:
IMPROVE: Rename ivy configuration in settings to remove ambiguity on configuration meaning (IVY-438)
previous commits did the code change, this one finishes the task with doc update
Modified:
incubator/ivy/core/trunk/CHANGES.txt
incubator/ivy/core/trunk/doc/doc/configuration.html
incubator/ivy/core/trunk/doc/doc/configuration/conf.html
incubator/ivy/core/trunk/doc/doc/intro.html
incubator/ivy/core/trunk/doc/doc/terminology.html
incubator/ivy/core/trunk/doc/doc/tutorial/build-repository.html
incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced1.html
incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced2.html
incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/basic.html
incubator/ivy/core/trunk/doc/doc/tutorial/conf.html
incubator/ivy/core/trunk/doc/doc/tutorial/defaultconf.html
incubator/ivy/core/trunk/doc/doc/tutorial/dual.html
incubator/ivy/core/trunk/doc/doc/tutorial/ivyrep.html
incubator/ivy/core/trunk/doc/doc/tutorial/multi-project.html
incubator/ivy/core/trunk/doc/doc/tutorial/multiple.html
incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html
incubator/ivy/core/trunk/doc/doc/tutorial/start.html
incubator/ivy/core/trunk/doc/doc/use/configure.html
incubator/ivy/core/trunk/doc/toc.json
Modified: incubator/ivy/core/trunk/CHANGES.txt
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/CHANGES.txt?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/CHANGES.txt (original)
+++ incubator/ivy/core/trunk/CHANGES.txt Mon Mar 19 06:14:32 2007
@@ -9,6 +9,7 @@
=====================================
- NEW: define artifacts not declared by the dependency module descriptor (IVY-419)
+- IMPROVE: Rename ivy configuration in settings to remove ambiguity on configuration meaning (IVY-438)
- IMPROVE: Please typedef CacheResolver as "cache" for us (IVY-359)
- IMPROVE: ivy:retrieve should be able to create symlinks (IVY-353) (thanks to John Williams)
- IMPROVE: Ability to have multiple roots in the <ivy:buildfilelist> task (IVY-340) (thanks to Matt Inger)
Modified: incubator/ivy/core/trunk/doc/doc/configuration.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/configuration.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/configuration.html (original)
+++ incubator/ivy/core/trunk/doc/doc/configuration.html Mon Mar 19 06:14:32 2007
@@ -5,129 +5,128 @@
<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 ivysettings.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">
-<ivysettings>
- <properties file="${ivy.settings.dir}/ivysettings-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>
-</ivysettings>
-</code>
-
-<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 ivysettings-file.properties in the same directory as the configuration file, with ivy variables you want in it.</i>
-
-Some useful variables are available in ivysettings files:
-<ul>
-<li>ivy.settings.dir</li> this variable references the directory in which the ivysettings itself is. This is available if the ivysettings 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.settings.file</li>the path of the ivysettings 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.settings.url</li>the url pointing to the ivysettings 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>
-ivysettings
- <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>ivysettings</h1>
-<b>Tag:</b> ivysettings
-
-Root tag of any ivysettings 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 ivysettings 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 id="xooki-source">
+In order to work as you want, ivy sometimes need some settings. Actually, ivy can work with no specific settings at all, see the <a href="../doc/tutorial/defaultconf.html">default settings documentation</a> for details about that. But ivy is able
+to work in very different contexts. You just have to configure it properly.
+
+Settings are specified through an xml file, usually called ivysettings.xml. To configure ivy from ant, you just have to call the configure task and pass it the path to your settings file (see <a href="../doc/use/configure.html">configure</a> task documentation for details).
+
+Here is an example of settings file :
+<code type="xml">
+<ivysettings>
+ <properties file="${ivy.settings.dir}/ivysettings-file.properties" />
+ <settings 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>
+</ivysettings>
+</code>
+
+<br/>
+Mainly, the settings enable 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 settings file needs a property file named ivysettings-file.properties in the same directory as the settings file, with ivy variables you want in it.</i>
+
+Some useful variables are available in settings files:
+<ul>
+<li>ivy.settings.dir</li> this variable references the directory in which the ivysettings itself is. This is available if the settings 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.settings.file</li>the path of the settings 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.settings.url</li>the url pointing to the settings 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 settings file.
+
+<h1>Settings file structure</h1>
+
+The settings file is structured in some parts and left other open. Indeed each resolver has its own structure, thus it's not the settings file itself which define the structure for the resolvers.
+
+<pre>
+ivysettings
+ <a href="../doc/configuration/property.html">property</a>
+ <a href="../doc/configuration/properties.html">properties</a>
+ <a href="../doc/configuration/conf.html">settings</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>ivysettings</h1>
+<b>Tag:</b> ivysettings
+
+Root tag of any ivysettings 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">settings</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 settings 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>
Modified: incubator/ivy/core/trunk/doc/doc/configuration/conf.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/configuration/conf.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/configuration/conf.html (original)
+++ incubator/ivy/core/trunk/doc/doc/configuration/conf.html Mon Mar 19 06:14:32 2007
@@ -5,59 +5,57 @@
<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 id="xooki-source">
+<b>Tag:</b> settings
+
+Configures some important ivy info: default cache, default resolver, ...
+
+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 else 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>
Modified: incubator/ivy/core/trunk/doc/doc/intro.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/intro.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/intro.html (original)
+++ incubator/ivy/core/trunk/doc/doc/intro.html Mon Mar 19 06:14:32 2007
@@ -6,36 +6,36 @@
</head>
<body>
<textarea id="xooki-source">
-Welcome to Ivy reference documentation!
-
-If you don't know Ivy at all, give a glance at its <a href="../features.html">features</a>, the <a href="../faq.html">FAQ</a> and the <a href="../doc/tutorial.html">tutorials</a> before digging into this reference documentation.
-
-<h1>Reference Overview</h1>
-This documentation is decomposed in several parts:
-<ul>
-<li>Introduction</li>
-<ul>
-<li><a href="../doc/terminology.html">Terminology</a></li>
-This part gives you the meaning of some words used all over ivy doc, such as organisation, module, configurations, ...
-<li><a href="../doc/concept.html">Main Concepts</a></li>
-This part introduces the main concepts used in Ivy: dependency resolvers, variables, patterns, and also a good introduction to a central ivy concept: module configurations.
-<li><a href="../doc/principle.html">How does it work ?</a></li>
-As the title suggest, here you will have some explanations on how does ivy work internally, which can help to better understand and customize its use.
-<li><a href="../doc/install.html">Installation</a></li>
-This part describe how to install Ivy
-</ul>
-<li><a href="../doc/configuration.html">Configuration</a></li>
-This part is dedicated to the specification of the configuration file of Ivy (usually called ivysettings.xml). It also gives the list of built-in dependency resolvers available in ivy.
-<li><a href="../doc/ivyfile.html">Ivy files</a></li>
-This part is the reference of the specification of the ivy files, the files in which you describe your dependencies. If you have any question of what can be done or not in an ivy file, you will have the answer here.
-<li><a href="../doc/ant.html">Use from ant</a></li>
-This part describes how to use ivy from ant. It's in this section that all ant tasks brought by ivy are specified.
-<li><a href="../doc/ant.html">Use standalone</a></li>
-Even if Ivy is most often used from ant, it can also be used from the command line. This page describes how you can do it.
-<li><a href="../doc/extend.html">Extend</a></li>
-This part describes how to extend ivy, by writing your own dependency resolver, latest strategy, etc.
-</ul>
-
+Welcome to Ivy reference documentation!
+
+If you don't know Ivy at all, give a glance at its <a href="../features.html">features</a>, the <a href="../faq.html">FAQ</a> and the <a href="../doc/tutorial.html">tutorials</a> before digging into this reference documentation.
+
+<h1>Reference Overview</h1>
+This documentation is decomposed in several parts:
+<ul>
+<li>Introduction</li>
+<ul>
+<li><a href="../doc/terminology.html">Terminology</a></li>
+This part gives you the meaning of some words used all over ivy doc, such as organisation, module, configurations, settings, ...
+<li><a href="../doc/concept.html">Main Concepts</a></li>
+This part introduces the main concepts used in Ivy: dependency resolvers, variables, patterns, and also a good introduction to a central ivy concept: module configurations.
+<li><a href="../doc/principle.html">How does it work ?</a></li>
+As the title suggest, here you will have some explanations on how does ivy work internally, which can help to better understand and customize its use.
+<li><a href="../doc/install.html">Installation</a></li>
+This part describe how to install Ivy
+</ul>
+<li><a href="../doc/configuration.html">Settings</a></li>
+This part is dedicated to the specification of the settings file of Ivy (usually called ivysettings.xml). It also gives the list of built-in dependency resolvers available in ivy.
+<li><a href="../doc/ivyfile.html">Ivy files</a></li>
+This part is the reference of the specification of the ivy files, the files in which you describe your dependencies. If you have any question of what can be done or not in an ivy file, you will have the answer here.
+<li><a href="../doc/ant.html">Use from ant</a></li>
+This part describes how to use ivy from ant. It's in this section that all ant tasks brought by ivy are specified.
+<li><a href="../doc/ant.html">Use standalone</a></li>
+Even if Ivy is most often used from ant, it can also be used from the command line. This page describes how you can do it.
+<li><a href="../doc/extend.html">Extend</a></li>
+This part describes how to extend ivy, by writing your own dependency resolver, latest strategy, etc.
+</ul>
+
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
Modified: incubator/ivy/core/trunk/doc/doc/terminology.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/terminology.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/terminology.html (original)
+++ incubator/ivy/core/trunk/doc/doc/terminology.html Mon Mar 19 06:14:32 2007
@@ -5,58 +5,57 @@
<script type="text/javascript" src="../xooki/xooki.js"></script>
</head>
<body>
- <textarea id="xooki-source">
-Here are some terms used in Ivy, with their definitions in Ivy:<br/>
-<h2>Ivy file</h2>
-An ivy file is an xml file which is used to describe dependencies of a module (see below). It is usually named ivy.xml.
-<h2>Configuration file</h2>
-Ivy configuration files are xml files used to configure ivy to indicate where the dependencies can be found. This should not be confused with a module configuration (see below).
-<h2>Organisation</h2>
-An organisation is either a company or a simple group of person
-which produce software. Ivy handle only one level of organisation, so you cannot
-describe a company hierarchy with this concept. But it is used to group sofware
-produced by a same team, just to help find and classify them.<br/>
-<i>Examples: apache, ibm, jayasoft</i>
-<h2>Module</h2>
-A module in ivy is a piece of software that is reusable, and that
-follow a unique cycle of revision. <br/>
-<i>Examples: hibernate, ant, ...</i>
-<h2>Artifact</h2>
-An artifact is a single file produced by a company when releasing a module. In
-the java world, common artifacts are jars. In many cases, each revision of a
-module publish only one artifact (like log4j, for instance), but some of them
-publish many artifacts dependending on the use of the module (like ant, for instance).
-<h2>Revision</h2>
-A revision corresponds to one delivery of a module. It can either be a delivery
-of a release, a milestone, a beta version, a nightly build, or even a continuous
-build. All of them are considered revisions in ivy.
-<h2><a name="branch">Branch</a></h2>
-A branch corresponds to the standard meaning of a branch (or sometimes stream) in source control management tools.
-The head, or trunk, or main stream, is also considered as a branch in Ivy.
-<h2>Configuration</h2>
-A module configuration is a way to use or construct a module. Some modules may be
-used in different ways (think about hibernate which can be used inside or outside
-an application server), and this way may alter the artifacts you need (in the case
-of hibernate, jta.jar is needed only if it is used outside an application server).
-Moreover, a module may need some other modules and artifacts only at build time,
-and some others at runtime. All those differents ways to use or build a module
-are called in ivy configurations. <br/><br/>
-
-For more details on configurations and how they are used in ivy, please refer to the <a href="../doc/concept.html">main concepts page</a>.
-<h2>Status</h2>
-A module status indicates how stable a module revision can be considered. It can
-be used to consolidate the status of all the dependencies of a module, to prevent
-the use of an integration revision of a dependency in the release of your module.
-Three statuses are defined by default in ivy:
-<ul>
-<li>integration: revisions builded by a continuous build, a nightly build, and so on, fall in this category</li>
-<li>milestone: revisions delivered to the public but not actually finished fall in this category</li>
-<li>release: revision fully tested and labelled fall in this category</li>
-</ul>
-<span class="since">since 1.4</span> This list is <a href="../doc/configuration/statuses.html">configurable</a> in your configuration file.
-<h2>Repository</h2>
-What is called a repository in Ivy is a location where Ivy is able to find your modules artifacts and metadata (i.e. ivy files in most cases).
-Ivy can be used with complex repositories configured very finely. You can use <a href="../doc/concept.html">Dependency Resolvers</a> to do so.
+ <textarea id="xooki-source">
+Here are some terms used in Ivy, with their definitions in Ivy:<br/>
+<h2>Ivy file</h2>
+An ivy file is an xml file which is used to describe dependencies of a module (see below). It is usually named ivy.xml.
+<h2>Settings</h2>
+Ivy settings files are xml files used to configure ivy to indicate where the dependencies can be found and how.
+<em>Prior to Ivy 1.5, these files were called configuration files and usually named ivyconf.xml. This resulted in a confusion between module configurations and configuration files, so they have been renamed in settings files.
+If you happen to fall on an ivyconf file or something called a configuration file, most of the time it's only a problem of update of the doc/tutorial/article. Feel free to report any problem like this if you find such inconsistencies in this documentation.</em>
+<h2>Organisation</h2>
+An organisation is either a company or a simple group of person
+which produce software. Ivy handle only one level of organisation, so you cannot
+describe a company hierarchy with this concept. But it is used to group sofware
+produced by a same team, just to help find and classify them.<br/>
+<i>Examples: apache, ibm, jayasoft</i>
+<h2>Module</h2>
+A module in ivy is a piece of software that is reusable, and that
+follow a unique cycle of revision. <br/>
+<i>Examples: hibernate, ant, ...</i>
+<h2>Artifact</h2>
+An artifact is a single file produced by a company when releasing a module. In
+the java world, common artifacts are jars. In many cases, each revision of a
+module publish only one artifact (like log4j, for instance), but some of them
+publish many artifacts dependending on the use of the module (like ant, for instance).
+<h2>Revision</h2>
+A revision corresponds to one delivery of a module. It can either be a delivery
+of a release, a milestone, a beta version, a nightly build, or even a continuous
+build. All of them are considered revisions in ivy.
+<h2><a name="branch">Branch</a></h2>
+A branch corresponds to the standard meaning of a branch (or sometimes stream) in source control management tools.
+The head, or trunk, or main stream, is also considered as a branch in Ivy.
+<h2>Configuration</h2>
+A module configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server).
+Moreover, a module may need some other modules and artifacts only at build time,
+and some others at runtime. All those differents ways to use or build a module
+are called in ivy configurations.
+
+For more details on configurations and how they are used in ivy, please refer to the <a href="../doc/concept.html">main concepts page</a>.
+<h2>Status</h2>
+A module status indicates how stable a module revision can be considered. It can
+be used to consolidate the status of all the dependencies of a module, to prevent
+the use of an integration revision of a dependency in the release of your module.
+Three statuses are defined by default in ivy:
+<ul>
+<li>integration: revisions builded by a continuous build, a nightly build, and so on, fall in this category</li>
+<li>milestone: revisions delivered to the public but not actually finished fall in this category</li>
+<li>release: revision fully tested and labelled fall in this category</li>
+</ul>
+<span class="since">since 1.4</span> This list is <a href="../doc/configuration/statuses.html">configurable</a> in your configuration file.
+<h2>Repository</h2>
+What is called a repository in Ivy is a location where Ivy is able to find your modules artifacts and metadata (i.e. ivy files in most cases).
+Ivy can be used with complex repositories configured very finely. You can use <a href="../doc/concept.html">Dependency Resolvers</a> to do so.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
Modified: incubator/ivy/core/trunk/doc/doc/tutorial/build-repository.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/tutorial/build-repository.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/tutorial/build-repository.html (original)
+++ incubator/ivy/core/trunk/doc/doc/tutorial/build-repository.html Mon Mar 19 06:14:32 2007
@@ -5,37 +5,37 @@
<script type="text/javascript" src="../../xooki/xooki.js"></script>
</head>
<body>
- <textarea id="xooki-source">
-With the <a href="../../doc/use/install.html">install</a> ant task you are given the possibility to copy ivy descriptors and artifacts found from a resolver and publish them into another resolver.<br/>
-
-This tutorial will show you how to build your own clean enterprise repository of ivy descriptors and modules artifacts.
-We will first use some basic ivy configuration files to show how it works, and then we will use advanced features like <a href="../../doc/configuration/namespaces.html">namespaces</a> to build a real enterprise repository.
-
-<h1>The project used</h1>
-The project that we will use is quite simple.
-It is compouned of an ant build file, and some ivy conf files.
-
-Here are the accessible target that we will use :
-<div class="shell"><pre>
-Z:\ivy-repository>ant -p
-Buildfile: build.xml
-
-Main targets:
-
- advanced --> retrieve files from public repositories (ivyrep, ibiblio, ...) using namespaces
- basic --> retrieve files from well formatted ivy repositories
- basic-deps --> retrieve files from well formatted ivy repositories with dependencies
- clean-cache --> clean the cache
- clean-repo --> clean the destination repository
- commons-lang-1-0-ibiblio-no-namespace --> retrieve commons-lang 1.0 from ibiblio maven using no namespaces
- commons-lang-1-0-ibiblio-with-namespace --> retrieve commons-lang 1.0 from ibiblio maven using namespaces
- maven1 --> retrieve commons-lang 1.0 from maven1 repo using namespaces
- maven2 --> retrieve files from maven2 repo using namespaces
-Default target: basic</pre></div>
-<br/><br/>
-The project is accessible in the <a href="/latest/ivy">sources</a> of Ivy into : IVY_HOME/src/example/build-a-ivy-repository
-
-
+ <textarea id="xooki-source">
+With the <a href="../../doc/use/install.html">install</a> ant task you are given the possibility to copy ivy descriptors and artifacts found from a resolver and publish them into another resolver.<br/>
+
+This tutorial will show you how to build your own clean enterprise repository of ivy descriptors and modules artifacts.
+We will first use some basic ivy settings files to show how it works, and then we will use advanced features like <a href="../../doc/configuration/namespaces.html">namespaces</a> to build a real enterprise repository.
+
+<h1>The project used</h1>
+The project that we will use is quite simple.
+It is composed of an ant build file, and some ivy settings files.
+
+Here are the accessible target that we will use :
+<div class="shell"><pre>
+Z:\ivy-repository>ant -p
+Buildfile: build.xml
+
+Main targets:
+
+ advanced --> retrieve files from public repositories (ivyrep, ibiblio, ...) using namespaces
+ basic --> retrieve files from well formatted ivy repositories
+ basic-deps --> retrieve files from well formatted ivy repositories with dependencies
+ clean-cache --> clean the cache
+ clean-repo --> clean the destination repository
+ commons-lang-1-0-ibiblio-no-namespace --> retrieve commons-lang 1.0 from ibiblio maven using no namespaces
+ commons-lang-1-0-ibiblio-with-namespace --> retrieve commons-lang 1.0 from ibiblio maven using namespaces
+ maven1 --> retrieve commons-lang 1.0 from maven1 repo using namespaces
+ maven2 --> retrieve files from maven2 repo using namespaces
+Default target: basic</pre></div>
+<br/><br/>
+The project is accessible in the <a href="/latest/ivy">sources</a> of Ivy into : IVY_HOME/src/example/build-a-ivy-repository
+
+
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
Modified: incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced1.html
URL: http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced1.html?view=diff&rev=519939&r1=519938&r2=519939
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced1.html (original)
+++ incubator/ivy/core/trunk/doc/doc/tutorial/build-repository/advanced1.html Mon Mar 19 06:14:32 2007
@@ -5,181 +5,181 @@
<script type="text/javascript" src="../../../xooki/xooki.js"></script>
</head>
<body>
- <textarea id="xooki-source">
-<h1>On the road to a professional repository</h1>
-We will study in this section how to build a <strong>professionnal</strong> repository. What is a <strong>professionnal</strong> dependency resolver ? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer corrects, usuables, configurables and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository.
-We have seen in the previous example, that we could use some public repositories to begin to build our own repository.
-Nevertheless, the result is not at all the one that was excepected. Indeed there is a problem with public repositories : their partial incompatibility.
-For example, in <a href="http://ivyrep.jayasoft.org">ivyrep</a> all commons-* projects belong to the apache organisation. In both ibiblio versions, it is not the case. The same problem could appear for other projects with other repositories, it is not the debate here.
-
-To resolve some of the incompatibilities, we will use a new feature of <a href="/ivy">ivy</a> 1.3 the <a href="/ivy">namespaces</a>.
-
-<h1>Using namespaces</h1>
-In order to use namespaces, we first need to see what's happening when none are used on repositories that do not fit our needs.
-Let's take commons-lang 1.0 from ibiblio with a maven2 pom.
-First clean your cache and repository.
-<div class="shell"><pre>Z:\ivy-repository>ant clean-cache clean-repo</pre></div>
-Then call the good ant target : ant commons-lang-1-0-ibiblio-no-namespace
-<div class="shell"><pre>Z:\ivy-repository>ant commons-lang-1-0-ibiblio-no-namespace
-Buildfile: build.xml
-
-init-advanced:
-:: Ivy 20060125070719 - 20060125070719 :: http://ivy.jayasoft.org/ ::
-:: configuring :: file = Z:\ivy-repository\ivy-conf-advanced.xml
-
-commons-lang-1-0-ibiblio-no-namespace:
-:: installing [ commons-lang | commons-lang | 1.0 ] ::
-:: resolving dependencies ::
- found [ commons-lang | commons-lang | 1.0 ] in ibiblio-maven2-nonamespace
- found [ junit | junit | 3.7 ] in ibiblio-maven2-nonamespace
-:: downloading artifacts to cache ::
-downloading http://www.ibiblio.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0.jar ...
-.............. (62kB)
- [SUCCESSFUL ] [ commons-lang | commons-lang | 1.0 ]/commons-lang.jar[jar] (1313ms)
-downloading http://www.ibiblio.org/maven2/junit/junit/3.7/junit-3.7.jar ...
-.............
-.............. (114kB)
- [SUCCESSFUL ] [ junit | junit | 3.7 ]/junit.jar[jar] (2360ms)
-:: installing in local-repository ::
- published commons-lang to Z:\ivy-repository/ivy-local-repository/commons-lang/commons-lang/jars/commons-lang-1.0.jar
- published ivy to Z:\ivy-repository/ivy-local-repository/commons-lang/commons-lang/ivys/ivy-1.0.xml
- published junit to Z:\ivy-repository/ivy-local-repository/junit/junit/jars/junit-3.7.jar
- published ivy to Z:\ivy-repository/ivy-local-repository/junit/junit/ivys/ivy-3.7.xml
-:: install resolution report ::
- ---------------------------------------------------------------------
- | | modules || artifacts |
- | conf | number| search|dwnlded|evicted|| number|dwnlded|
- ---------------------------------------------------------------------
- | default | 2 | 2 | 2 | 0 || 2 | 2 |
- ---------------------------------------------------------------------
-
-BUILD SUCCESSFUL
-Total time: 6 seconds
-Z:\ivy-repository></pre></div>
-If we take a look at the repository, we can see that we respect the ibiblio maven2 architecture, the organisation apache does not appear.
-<div class="shell"><pre>Z:\ivy-repository>dir /s /B /A:-D ivy-local-repository
-Z:\ivy-repository\ivy-local-repository\commons-lang\commons-lang\ivys\ivy-1.0.xml
-Z:\ivy-repository\ivy-local-repository\commons-lang\commons-lang\jars\commons-lang-1.0.jar
-Z:\ivy-repository\ivy-local-repository\junit\junit\ivys\ivy-3.7.xml
-Z:\ivy-repository\ivy-local-repository\junit\junit\jars\junit-3.7.jar</pre></div>
-If you take a look at the ivy descriptor for commons-lang, you will see that the organisation is still commons-lang. It could not be another thing as we did not do anything for it.
-<div><code type="xml">
-<ivy-module version="1.0">
- <info organisation="commons-lang"
- module="commons-lang"
- revision="1.0"
- status="integration"
- publication="20051124062021"
- />
-</code></div>
-
-<h2>Introduction to namespaces</h2>
-Let's see directly the result, we will have some explanations after.
-Clean your repo and cache, and call : ant commons-lang-1-0-ibiblio-with-namespace
-<div class="shell"><pre>Z:\ivy-repository>ant commons-lang-1-0-ibiblio-with-namespace
-Buildfile: build.xml
-
-init-advanced:
-:: Ivy non official version :: http://ivy.jayasoft.org/ ::
-:: configuring :: file = Z:\ivy-repository\ivy-conf-advanced.xml
-
-commons-lang-1-0-ibiblio-with-namespace:
-:: installing [ apache | commons-lang | 1.0 ] ::
-:: resolving dependencies ::
- found [ apache | commons-lang | 1.0 ] in ibiblio-maven2
- found [ junit | junit | 3.7 ] in ibiblio-maven2
-:: downloading artifacts to cache ::
-downloading http://www.ibiblio.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0.jar ...
-............. (62kB)
- [SUCCESSFUL ] [ apache | commons-lang | 1.0 ]/commons-lang.jar[jar] (1094ms)
-downloading http://www.ibiblio.org/maven2/junit/junit/3.7/junit-3.7.jar ...
-............................ (114kB)
- [SUCCESSFUL ] [ junit | junit | 3.7 ]/junit.jar[jar] (1641ms)
-:: installing in local-repository ::
- published commons-lang to Z:\ivy-repository/ivy-local-repository/apache/commons-lang/jars/commons-lang-1.0.jar
- published ivy to Z:\ivy-repository/ivy-local-repository/apache/commons-lang/ivys/ivy-1.0.xml
- published junit to Z:\ivy-repository/ivy-local-repository/junit/junit/jars/junit-3.7.jar
- published ivy to Z:\ivy-repository/ivy-local-repository/junit/junit/ivys/ivy-3.7.xml
-:: install resolution report ::
- ---------------------------------------------------------------------
- | | modules || artifacts |
- | conf | number| search|dwnlded|evicted|| number|dwnlded|
- ---------------------------------------------------------------------
- | default | 2 | 2 | 2 | 0 || 2 | 2 |
- ---------------------------------------------------------------------
-
-BUILD SUCCESSFUL
-Total time: 5 seconds</pre></div>
-Now if we look at our repository, it seems to look fine.
-<div class="shell"><pre>Z:\ivy-repository>dir /s /B /A:-D ivy-local-repository
-Z:\ivy-repository\ivy-local-repository\apache\commons-lang\ivys\ivy-1.0.xml
-Z:\ivy-repository\ivy-local-repository\apache\commons-lang\jars\commons-lang-1.0.jar
-Z:\ivy-repository\ivy-local-repository\junit\junit\ivys\ivy-3.7.xml
-Z:\ivy-repository\ivy-local-repository\junit\junit\jars\junit-3.7.jar</pre></div>
-Have a look at the ivy file to see it it looks better than before. Ok, we have now our apache organisation.
-<div><code type="xml">
-<ivy-module version="1.0">
- <info organisation="apache"
- module="commons-lang"
- revision="1.0"
- status="integration"
- publication="20051124062021"
- />
-</code></div>
-<h2>How does this work ?</h2>
-If we look at the ant target commons-lang-1-0-ibiblio-with-namespace, we can see that it uses a resolver called ibiblio-maven2.
-Let's find it... The configuration file used for this test is ivy-conf-advanced.xml. This one includes ivy-maven2-ivysettings.xml where the required resolver is defined.
-Let's see it's definition :
-<code type="xml"><ibiblio name="ibiblio-maven2"
- root="${ibiblio-maven2-root}"
- pattern="${ibiblio-maven2-pattern}"
- m2compatible="true"
- namespace="ibiblio-maven2"
-/></code>Ok, i see it, it is a ibiblio resolver for which we specify the root and the pattern. The important things here are the 2 other parameters.
-<ul><li><b>m2compatible</b> is a flag telling that we allow reading POMs file and make some transformations on URLs regarding the organisation name. Indeed, maven transforms organisations like "org.apache" into "some_url/org/apache" to retrieve information on ibiblio repositories.</li>
-<li><b>namespace</b> this attribute defines a domain in which same projects (meanning organsiation, module or revision) can be nammed whith differents kinds.</li></ul>
-
-A namespace is defined by a set of rule, for ibiblio-maven2, whe have declared some rules :
-<h3>rule handling imported apache maven1 projects</h3>
-<code type="xml"><rule> <!-- imported apache maven1 projects -->
- <fromsystem>
- <src org="apache" module=".+"/>
-
- <dest org="$m0" module="$m0"/>
- </fromsystem>
- <tosystem>
- <src org="commons-.+" module="commons-.+" />
- <src org="ant.*" module="ant.*" />
- ...
- <src org="xmlrpc" module="xmlrpc" />
-
- <dest org="apache" module="$m0"/>
- </tosystem>
-</rule></code>
-<div class="postit"><u>Note about regular expressions usage :</u>
-In order to distinguish matching regular expressions found in organisation, module & revision the notation used prefixes the matching regular expression with the letters 'o', 'm' & 'r'.
-$o0 : the whole regular expression term in the organisation attribute
-$o1 : the first matching expression term that was marked in the organisation attribute
-...
-The same applies for modules : $m0, $m1, ...
-and for revisions : $r0, $r1, ...
-</div>
-<ul>
-<li><b>fromsystem :</b> we define here that the projects defined in the system under the organisation called "apache" are transformed into the destination namespace (whose resolver it applies) into projects whose organisation is nammed with the module name, we don't care here about the revision. For example, the project ['apache', 'commons-lang', '1.0'] in the namespace system will be translated into ['commons-lang', 'commons-lang', '1.0'] in the ibiblio-maven2 resolver namespace.</li>
-<li><b>tosystem :</b> we define here the reverse mapping, ie how to translate <em>apache</em> projects from ibiblio into real apache projects in the namespace system. The rule here, is telling that all projects matching commons-.+ (see it as java regular expression) for their organisation name and module name are transformed into projects whose organisation is apache with the module name as it was found. The same kind of rule is applied for others apache projects like ant, etc. For example, ['ant','ant','1.6.2'] in ibiblio-maven2 namespace will become ['apache','ant','1.6.2'] int the system namespace.</li>
-</ul>
-<h3>rule handling new apache projects</h3>
-<code type="xml"><rule> <!-- new apache projects -->
- <fromsystem>
- <src org="apache" />
- <dest org="org.apache"/>
- </fromsystem>
- <tosystem>
- <src org="org.apache" />
- <dest org="apache" />
- </tosystem>
-</rule></code>
-The mapping adds or removes the package 'org' before the organisation name to conform to maven2 choices.
+ <textarea id="xooki-source">
+<h1>On the road to a professional repository</h1>
+We will study in this section how to build a <strong>professionnal</strong> repository. What is a <strong>professionnal</strong> repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer corrects, usuables, configurables and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository.
+We have seen in the previous example, that we could use some public repositories to begin to build our own repository.
+Nevertheless, the result is not at all the one that was expected. Indeed there is a problem with public repositories: their partial incompatibility.
+For example, in <a href="http://ivyrep.jayasoft.org">ivyrep</a> all commons-* projects belong to the apache organisation. In both ibiblio versions, it is not the case. The same problem could appear for other projects with other repositories, it is not the debate here.
+
+To resolve some of the incompatibilities, we will use a new feature of <a href="/ivy">ivy</a> 1.3 the <a href="/ivy">namespaces</a>.
+
+<h1>Using namespaces</h1>
+In order to use namespaces, we first need to see what's happening when none are used on repositories that do not fit our needs.
+Let's take commons-lang 1.0 from ibiblio with a maven2 pom.
+First clean your cache and repository.
+<div class="shell"><pre>Z:\ivy-repository>ant clean-cache clean-repo</pre></div>
+Then call the good ant target : ant commons-lang-1-0-ibiblio-no-namespace
+<div class="shell"><pre>Z:\ivy-repository>ant commons-lang-1-0-ibiblio-no-namespace
+Buildfile: build.xml
+
+init-advanced:
+:: Ivy 20060125070719 - 20060125070719 :: http://ivy.jayasoft.org/ ::
+:: configuring :: file = Z:\ivy-repository\ivy-conf-advanced.xml
+
+commons-lang-1-0-ibiblio-no-namespace:
+:: installing [ commons-lang | commons-lang | 1.0 ] ::
+:: resolving dependencies ::
+ found [ commons-lang | commons-lang | 1.0 ] in ibiblio-maven2-nonamespace
+ found [ junit | junit | 3.7 ] in ibiblio-maven2-nonamespace
+:: downloading artifacts to cache ::
+downloading http://www.ibiblio.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0.jar ...
+.............. (62kB)
+ [SUCCESSFUL ] [ commons-lang | commons-lang | 1.0 ]/commons-lang.jar[jar] (1313ms)
+downloading http://www.ibiblio.org/maven2/junit/junit/3.7/junit-3.7.jar ...
+.............
+.............. (114kB)
+ [SUCCESSFUL ] [ junit | junit | 3.7 ]/junit.jar[jar] (2360ms)
+:: installing in local-repository ::
+ published commons-lang to Z:\ivy-repository/ivy-local-repository/commons-lang/commons-lang/jars/commons-lang-1.0.jar
+ published ivy to Z:\ivy-repository/ivy-local-repository/commons-lang/commons-lang/ivys/ivy-1.0.xml
+ published junit to Z:\ivy-repository/ivy-local-repository/junit/junit/jars/junit-3.7.jar
+ published ivy to Z:\ivy-repository/ivy-local-repository/junit/junit/ivys/ivy-3.7.xml
+:: install resolution report ::
+ ---------------------------------------------------------------------
+ | | modules || artifacts |
+ | conf | number| search|dwnlded|evicted|| number|dwnlded|
+ ---------------------------------------------------------------------
+ | default | 2 | 2 | 2 | 0 || 2 | 2 |
+ ---------------------------------------------------------------------
+
+BUILD SUCCESSFUL
+Total time: 6 seconds
+Z:\ivy-repository></pre></div>
+If we take a look at the repository, we can see that we respect the ibiblio maven2 architecture, the organisation apache does not appear.
+<div class="shell"><pre>Z:\ivy-repository>dir /s /B /A:-D ivy-local-repository
+Z:\ivy-repository\ivy-local-repository\commons-lang\commons-lang\ivys\ivy-1.0.xml
+Z:\ivy-repository\ivy-local-repository\commons-lang\commons-lang\jars\commons-lang-1.0.jar
+Z:\ivy-repository\ivy-local-repository\junit\junit\ivys\ivy-3.7.xml
+Z:\ivy-repository\ivy-local-repository\junit\junit\jars\junit-3.7.jar</pre></div>
+If you take a look at the ivy descriptor for commons-lang, you will see that the organisation is still commons-lang. It could not be another thing as we did not do anything for it.
+<div><code type="xml">
+<ivy-module version="1.0">
+ <info organisation="commons-lang"
+ module="commons-lang"
+ revision="1.0"
+ status="integration"
+ publication="20051124062021"
+ />
+</code></div>
+
+<h2>Introduction to namespaces</h2>
+Let's see directly the result, we will have some explanations after.
+Clean your repo and cache, and call : ant commons-lang-1-0-ibiblio-with-namespace
+<div class="shell"><pre>Z:\ivy-repository>ant commons-lang-1-0-ibiblio-with-namespace
+Buildfile: build.xml
+
+init-advanced:
+:: Ivy non official version :: http://ivy.jayasoft.org/ ::
+:: configuring :: file = Z:\ivy-repository\ivy-conf-advanced.xml
+
+commons-lang-1-0-ibiblio-with-namespace:
+:: installing [ apache | commons-lang | 1.0 ] ::
+:: resolving dependencies ::
+ found [ apache | commons-lang | 1.0 ] in ibiblio-maven2
+ found [ junit | junit | 3.7 ] in ibiblio-maven2
+:: downloading artifacts to cache ::
+downloading http://www.ibiblio.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0.jar ...
+............. (62kB)
+ [SUCCESSFUL ] [ apache | commons-lang | 1.0 ]/commons-lang.jar[jar] (1094ms)
+downloading http://www.ibiblio.org/maven2/junit/junit/3.7/junit-3.7.jar ...
+............................ (114kB)
+ [SUCCESSFUL ] [ junit | junit | 3.7 ]/junit.jar[jar] (1641ms)
+:: installing in local-repository ::
+ published commons-lang to Z:\ivy-repository/ivy-local-repository/apache/commons-lang/jars/commons-lang-1.0.jar
+ published ivy to Z:\ivy-repository/ivy-local-repository/apache/commons-lang/ivys/ivy-1.0.xml
+ published junit to Z:\ivy-repository/ivy-local-repository/junit/junit/jars/junit-3.7.jar
+ published ivy to Z:\ivy-repository/ivy-local-repository/junit/junit/ivys/ivy-3.7.xml
+:: install resolution report ::
+ ---------------------------------------------------------------------
+ | | modules || artifacts |
+ | conf | number| search|dwnlded|evicted|| number|dwnlded|
+ ---------------------------------------------------------------------
+ | default | 2 | 2 | 2 | 0 || 2 | 2 |
+ ---------------------------------------------------------------------
+
+BUILD SUCCESSFUL
+Total time: 5 seconds</pre></div>
+Now if we look at our repository, it seems to look fine.
+<div class="shell"><pre>Z:\ivy-repository>dir /s /B /A:-D ivy-local-repository
+Z:\ivy-repository\ivy-local-repository\apache\commons-lang\ivys\ivy-1.0.xml
+Z:\ivy-repository\ivy-local-repository\apache\commons-lang\jars\commons-lang-1.0.jar
+Z:\ivy-repository\ivy-local-repository\junit\junit\ivys\ivy-3.7.xml
+Z:\ivy-repository\ivy-local-repository\junit\junit\jars\junit-3.7.jar</pre></div>
+Have a look at the ivy file to see it it looks better than before. Ok, we have now our apache organisation.
+<div><code type="xml">
+<ivy-module version="1.0">
+ <info organisation="apache"
+ module="commons-lang"
+ revision="1.0"
+ status="integration"
+ publication="20051124062021"
+ />
+</code></div>
+<h2>How does this work ?</h2>
+If we look at the ant target commons-lang-1-0-ibiblio-with-namespace, we can see that it uses a resolver called ibiblio-maven2.
+Let's find it... The configuration file used for this test is ivysettings-advanced.xml. This one includes ivy-maven2-ivysettings.xml where the required resolver is defined.
+Let's see it's definition :
+<code type="xml"><ibiblio name="ibiblio-maven2"
+ root="${ibiblio-maven2-root}"
+ pattern="${ibiblio-maven2-pattern}"
+ m2compatible="true"
+ namespace="ibiblio-maven2"
+/></code>Ok, i see it, it is a ibiblio resolver for which we specify the root and the pattern. The important things here are the 2 other parameters.
+<ul><li><b>m2compatible</b> is a flag telling that we allow reading POMs file and make some transformations on URLs regarding the organisation name. Indeed, maven transforms organisations like "org.apache" into "some_url/org/apache" to retrieve information on ibiblio repositories.</li>
+<li><b>namespace</b> this attribute defines a domain in which same projects (meaning organsiation, module or revision) can be named whith differents kinds.</li></ul>
+
+A namespace is defined by a set of rule, for ibiblio-maven2, we have declared some rules:
+<h3>rule handling imported apache maven1 projects</h3>
+<code type="xml"><rule> <!-- imported apache maven1 projects -->
+ <fromsystem>
+ <src org="apache" module=".+"/>
+
+ <dest org="$m0" module="$m0"/>
+ </fromsystem>
+ <tosystem>
+ <src org="commons-.+" module="commons-.+" />
+ <src org="ant.*" module="ant.*" />
+ ...
+ <src org="xmlrpc" module="xmlrpc" />
+
+ <dest org="apache" module="$m0"/>
+ </tosystem>
+</rule></code>
+<div class="postit"><u>Note about regular expressions usage :</u>
+In order to distinguish matching regular expressions found in organisation, module & revision the notation used prefixes the matching regular expression with the letters 'o', 'm' & 'r'.
+$o0 : the whole regular expression term in the organisation attribute
+$o1 : the first matching expression term that was marked in the organisation attribute
+...
+The same applies for modules : $m0, $m1, ...
+and for revisions : $r0, $r1, ...
+</div>
+<ul>
+<li><b>fromsystem :</b> we define here that the projects defined in the system under the organisation called "apache" are transformed into the destination namespace (whose resolver it applies) into projects whose organisation is named with the module name, we don't care here about the revision. For example, the project ['apache', 'commons-lang', '1.0'] in the namespace system will be translated into ['commons-lang', 'commons-lang', '1.0'] in the ibiblio-maven2 resolver namespace.</li>
+<li><b>tosystem :</b> we define here the reverse mapping, ie how to translate <em>apache</em> projects from ibiblio into real apache projects in the namespace system. The rule here, is telling that all projects matching commons-.+ (see it as java regular expression) for their organisation name and module name are transformed into projects whose organisation is apache with the module name as it was found. The same kind of rule is applied for others apache projects like ant, etc. For example, ['ant','ant','1.6.2'] in ibiblio-maven2 namespace will become ['apache','ant','1.6.2'] int the system namespace.</li>
+</ul>
+<h3>rule handling new apache projects</h3>
+<code type="xml"><rule> <!-- new apache projects -->
+ <fromsystem>
+ <src org="apache" />
+ <dest org="org.apache"/>
+ </fromsystem>
+ <tosystem>
+ <src org="org.apache" />
+ <dest org="apache" />
+ </tosystem>
+</rule></code>
+The mapping adds or removes the package 'org' before the organisation name to conform to maven2 choices.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>