mirror of https://github.com/apache/ant-ivy
DOCUMENTATION: Fixed more than a hundred (100+) obsolete "configuration" references; replaced with "settings" (IVY-863) (thanks to Sakari Maaranen)
git-svn-id: https://svn.apache.org/repos/asf/ant/ivy/core/trunk@675856 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Xavier Hanin
parent
dbbccbf883
commit
2931da346c
|
|
@ -245,13 +245,13 @@ Ivy cache is composed of two different parts:
|
|||
<ul>
|
||||
<li>the repository cache</li>
|
||||
The repository cache is where Ivy stores data downloaded from module repositories, along with some meta information concerning these artifacts, like their original location.
|
||||
This part of the cache can be shared if you use a well suited [[configuration/lock-strategies lock strategy]].
|
||||
This part of the cache can be shared if you use a well suited [[settings/lock-strategies lock strategy]].
|
||||
<li>the resolution cache</li>
|
||||
This part of the cache is used to store resolution data, which is used by Ivy to reuse the results of a resolve process.
|
||||
This part of the cache is overwritten each time a new resolve is performed, and should never be used by multiple processes at the same time.
|
||||
</ul>
|
||||
|
||||
While there is always only one resolution cache, you can [[configuration/caches define multiple repository caches]], each [[configuration/resolvers resolver]] being able to use a separate cache.
|
||||
While there is always only one resolution cache, you can [[settings/caches define multiple repository caches]], each [[settings/resolvers resolver]] being able to use a separate cache.
|
||||
|
||||
<h2><a name="change">Change management</a></h2>
|
||||
To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and do not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several [[bestpractices good reasons]] to follow this principle.
|
||||
|
|
@ -264,7 +264,7 @@ In this case, setting checkModified="true" on your dependency resolver will be t
|
|||
<h3>Changes in artifacts</h3>
|
||||
Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps saves disk space to keep only one version for the high number of intermediary builds you can make whilst developing.
|
||||
|
||||
Ivy supports this kind of approach with the notion of changing revision. A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the [[ivyfile/dependency]] tag, or use the changingPattern and changingMatcher attributes on your [[configuration/resolvers]] to indicate which revision or group of revisions should be considered as changing.
|
||||
Ivy supports this kind of approach with the notion of changing revision. A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the [[ivyfile/dependency]] tag, or use the changingPattern and changingMatcher attributes on your [[settings/resolvers]] to indicate which revision or group of revisions should be considered as changing.
|
||||
|
||||
Once Ivy knows that a revision is changing, it will follow this principle to avoid checking your repository too often: if the module metadata has not changed, it will considered the whole module (including artifacts) as not changed. Even if the module descriptor file has changed, it will check the publication data of the module to see if this is a new publication of the same revision or not. Then if the publication date has changed, it will check the artifacts last modified timestamps, and download them accordingly.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,135 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 0};</script>
|
||||
<script type="text/javascript" src="xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=settings.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
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="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 use the [[ant:settings]] datatype with the path of your settings file.
|
||||
|
||||
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="configuration/property.html">property</a>
|
||||
<a href="configuration/properties.html">properties</a>
|
||||
<a href="configuration/conf.html">settings</a>
|
||||
<a href="configuration/include.html">include</a>
|
||||
<a href="configuration/classpath.html">classpath</a>
|
||||
<a href="configuration/typedef.html">typedef</a>
|
||||
<a href="configuration/lock-strategies.html">lock-strategies</a>
|
||||
<a href="configuration/caches.html">caches</a>
|
||||
<a href="configuration/caches/cache.html">cache</a>
|
||||
<a href="configuration/latest-strategies.html">latest-strategies</a>
|
||||
<a href="configuration/version-matchers.html">version-matchers</a>
|
||||
<a href="configuration/triggers.html">triggers</a>
|
||||
<a href="configuration/parsers.html">parsers</a>
|
||||
<a href="configuration/conflict-managers.html">conflict-managers</a>
|
||||
<a href="configuration/outputters.html">outputters</a>
|
||||
<a href="configuration/namespaces.html">namespaces</a>
|
||||
<a href="configuration/namespace.html">namespace</a>
|
||||
<a href="configuration/namespace/rule.html">rule</a>
|
||||
<a href="configuration/namespace/fromtosystem.html">fromsystem</a>
|
||||
<a href="configuration/namespace/src.html">src</a>
|
||||
<a href="configuration/namespace/dest.html">dest</a>
|
||||
<a href="configuration/namespace/fromtosystem.html">tosystem</a>
|
||||
<a href="configuration/namespace/src.html">src</a>
|
||||
<a href="configuration/namespace/dest.html">dest</a>
|
||||
<a href="configuration/macrodef.html">macrodef</a>
|
||||
<a href="configuration/macrodef/attribute.html">attribute</a>
|
||||
any resolver
|
||||
<a href="configuration/resolvers.html">resolvers</a>
|
||||
any resolver
|
||||
<a href="configuration/modules.html">modules</a>
|
||||
<a href="configuration/module.html">module</a>
|
||||
<a href="configuration/statuses.html">statuses</a>
|
||||
<a href="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="configuration/property.html">property</a></td><td>set an ivy variable</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="configuration/properties.html">properties</a></td><td>loads a properties file as ivy variables</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="configuration/conf.html">settings</a></td><td>configures ivy with some defaults</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/include.html">include</a></td><td>includes another settings file</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="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="configuration/typedef.html">typedef</a></td><td>defines new types in ivy</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="configuration/lock-strategies.html">lock-strategies</a></td><td>defines lock strategies</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/caches.html">caches</a></td><td>defines repository cache managers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/latest-strategies.html">latest-strategies</a></td><td>defines latest strategies</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/parsers.html">parsers</a></td><td>defines module descriptor parsers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/version-matchers.html">version-matchers</a></td><td>defines new version matchers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/triggers.html">triggers</a></td><td>register triggers on ivy events</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/namespaces.html">namespaces</a></td><td>defines new namespaces</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/macrodef.html">macrodef</a></td><td>defines a new macro resolver</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="configuration/resolvers.html">resolvers</a></td><td>defines dependency resolvers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/conflict-managers.html">conflict-managers</a></td><td>defines conflicts managers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/modules.html">modules</a></td><td>defines rules between modules and dependency resolvers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/outputters.html">outputters</a></td><td>defines the list of available report outputters</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="configuration/statuses.html">statuses</a></td><td>defines the list of available statuses</td>
|
||||
<td>0..1</td></tr>
|
||||
</tbody>
|
||||
</table></textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="settings.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,71 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/caches.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> caches
|
||||
|
||||
Configures the Ivy cache system. <span class="since">since 2.0</span>.
|
||||
See <a href="../concept.html#cache">cache concept</a> for details on the Ivy cache concept.
|
||||
|
||||
By default, Ivy defines one repository cache instance, called 'default-cache', which uses the default cache settings defined using attributes on this tag. This default instance is defined as long as you don't define your own default cache using the 'default' attribute, and have at least one dependency resolver which doesn't specify which cache instance to use.
|
||||
|
||||
<em>defaultCacheDir</em> is the default directory used for both the resolution and repository cache(s). It usually points to a directory in your filesystem. If you want to isolate resolution cache from repository cache, we recommend setting both the resolutionCacheDir and repositoryCacheDir attributes on this tag instead of using defaultCacheDir.
|
||||
|
||||
Since repository cache implementations are pluggable, you can either define new cache instances based on the default implementation provided in Ivy using the [[configuration/caches/cache]] child element, or use custom cache implementations using child elements as you have defined using [[configuration/typedef]].
|
||||
|
||||
<em>ivyPattern</em> and <em>artifactPattern</em> are used to configure the default way Ivy stores ivy files and artifacts in repository cache(s). Usually you do not have to change this, unless you want to use the cache directly from another tool, which is not recommended. These patterns are relative to the repository cache base directory.
|
||||
|
||||
<em>checkUpToDate</em> 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.
|
||||
|
||||
<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>default</td><td>the name of the default cache to use on all resolvers not defining the cache instance to use</td>
|
||||
<td>No, defaults to a default cache manager instance named 'default-cache'</td></tr>
|
||||
<tr><td>defaultCacheDir</td><td>a path to a directory to use as default basedir for both resolution and repository cache(s)</td>
|
||||
<td>No, defaults to .ivy2/cache in the user's home directory</td></tr>
|
||||
<tr><td>resolutionCacheDir</td><td>the path of the directory to use for all resolution cache data</td>
|
||||
<td>No, defaults to defaultCacheDir</td></tr>
|
||||
<tr><td>repositoryCacheDir</td><td>the path of the default directory to use for repository cache data. <strong>This should not point to a directory used as a repository!</strong></td>
|
||||
<td>No, defaults to defaultCacheDir</td></tr>
|
||||
<tr><td>ivyPattern</td><td>default pattern used to indicate where ivy files should be put in the repository cache(s)</td>
|
||||
<td>No, defaults to [organisation]/[module]/ivy-[revision].xml</td></tr>
|
||||
<tr><td>artifactPattern</td><td>default pattern used to indicate where artifact files should be put in the repository cache(s)</td>
|
||||
<td>No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]</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>useOrigin</td><td>the default value to use for useOrigin for caches in which it isn't specifically defined.
|
||||
Use true to avoid the copy of local artifacts to the cache and use directly their original location.</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
<tr><td>lockStrategy</td><td>the name of the default [[configuration/lock-strategies lock strategy]] to use when accessing repository cache(s)</td>
|
||||
<td>No, defaults to <em>no-lock</em></td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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><a href="caches/cache.html">cache</a></td><td>defines a new repository cache instance, based on the default repository cache implementation</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<caches>
|
||||
<cache name="mycache" basedir="path/to/my/cache/1" />
|
||||
<cache name="mycache2" basedir="path/to/my/cache/2" />
|
||||
</caches>
|
||||
</code>
|
||||
Define 2 cache instances, named mycache and mycache2, using two different directories as base directory, and using the default patterns and lock strategies. The default cache instance will still be defined as long as at least one dependency resolver does not declare which cache manager to use.
|
||||
<hr/></textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/caches.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,67 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/caches/cache.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> cache
|
||||
|
||||
Defines a repository cache instance based on the default repository cache implementation.
|
||||
|
||||
The default repository cache implementation caches files on the local filesystem in subdirectories of a configured base directory.
|
||||
|
||||
<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>name</td><td>name of the cache instance</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>basedir</td><td>the path of the base directory to use to put repository cache data. <strong>This should not point to a directory used as a repository!</strong></td>
|
||||
<td>No, defaults to repositoryCacheDir defined in [[configuration/caches]]</td></tr>
|
||||
<tr><td>ivyPattern</td><td>the pattern to use to store cached ivy files</td>
|
||||
<td>No, defaults to default cache ivy pattern as configured in [[configuration/caches]]</td></tr>
|
||||
<tr><td>artifactPattern</td><td>the pattern to use to store cached artifacts</td>
|
||||
<td>No, defaults to default cache artifact pattern as configured in [[configuration/caches]]</td></tr>
|
||||
<tr><td>useOrigin</td><td>true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise.
|
||||
To know if an artifact is local ivy asks to the resolver. Only filesystem resolver is considered local by default, but this can be disabled if you want to force the copy on one filesystem resolver and use the original location on another. Note that it is safe to use useOrigin even if you use the cache for some non local resolvers. In this case the cache will behave as usual, copying files to the cache. Note also that this only applies to artifacts, not to ivy files, which are still copied in the cache.</td>
|
||||
<td>No. defaults to the default value configured in [[configuration/caches]]</td></tr>
|
||||
<tr><td>lockStrategy</td><td>the name of the [[configuration/lock-strategies lock strategy]] to use for this cache</td>
|
||||
<td>No, defaults to default lock strategy as configured in [[configuration/caches]]</td></tr>
|
||||
<tr><td>defaultTTL</td><td>the default [[configuration/caches/ttl TTL]] to use when no specific one is defined</td>
|
||||
<td>No, defaults to ${ivy.cache.ttl.default}</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<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>[[configuration/caches/ttl]]</td><td>defines a TTL rule</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Examples</h1>
|
||||
<code>
|
||||
<cache name="mycache"
|
||||
basedir="/path/to/mycache"
|
||||
ivyPattern="[module]/ivy-[revision].xml"
|
||||
artifactPattern="[module]/[artifact]-[revision].[ext]"
|
||||
lockStrategy="no-lock"
|
||||
defaultTTL="1s">
|
||||
<ttl revision="latest.integration" duration="200ms" />
|
||||
<ttl organisation="org1" duration="10m 20s" />
|
||||
<ttl organisation="org2" duration="5h" />
|
||||
<ttl organisation="org3" duration="2d 12h" />
|
||||
</cache>
|
||||
</code>
|
||||
Defines a cache called 'mycache', storing files in the '/path/to/mycache' directory using '[module]/ivy-[revision].xml' as pattern to store Ivy files and '[module]/[artifact]-[revision].[ext]' as pattern to store other artifacts.
|
||||
The lock strategy used by this cache is the 'no-lock' strategy, which does not perform any locking.
|
||||
The defaultTTL used is of 1s, meaning that by default dynamic revision result will be stored and used for one second. TTL rules then define that all 'latest.integration' revisions will be stored and used for 200ms, while other dynamic revisions from org1 org2 and org3 modules will be stored respectively for 10 minutes 20 seconds; 5 hours; and 2 days and 12 hours.</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/caches/cache.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,48 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/caches/ttl.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> ttl
|
||||
|
||||
<span class="since">Since 2.0</span> Defines a TTL (Time To Live) rule for resolved revision caching.
|
||||
|
||||
When Ivy resolves a dynamic version constraint (like latest.integration or a version range), it can store the result of the resolution (like latest.integration=1.5.1) for a given time, called TTL. It means that Ivy will reuse this dynamic revision resolution result without accessing the repositories for the duration of the TTL, unless running [[ant:resolve]] in refresh mode.
|
||||
|
||||
This tag let you define a rule to define a TTL specific to a set of dynamic revision, based on the whole module revision information (organization, module name, revision, ...). The revision considered in the rule is the revision before the resolution (for instance 'latest.integration') and not the resolved revision (for instance '1.5.1').
|
||||
|
||||
The rules are evaluated in order, the first matching rule being used to define the TTL. If no rule matches, the cache defaultTTL will be used.
|
||||
|
||||
The format used to specify the TTL is of the form:
|
||||
<code>
|
||||
XXd XXh XXm XXs XXXms
|
||||
</code>
|
||||
Where 'd' stands for days, 'h' for hours, 'm' for minutes, 's' for seconds and 'ms' for milliseconds. Any part of the specification can be omitted, so '12d', '2h 5m' and '1d 5ms' are all valid.
|
||||
|
||||
Using a 0ms TTL disable resolved revision caching for the given rule.
|
||||
|
||||
<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>organisation</td><td>the organisation to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>module</td><td>the module's name to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>revision</td><td>the module's revision to match to apply the rule. Note that the version is not resolved when evaluating the rule ('latest.integration' for instance).</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td><em>any extra attribute</em></td><td>an extra attribute to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>matcher</td><td>the <a href="../../concept.html#matcher">matcher</a> to use to match the modules to which the resolver should be applied</td>
|
||||
<td>No, defaults to exact</td></tr>
|
||||
<tr><td>duration</td><td>the TTL to apply</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/caches/ttl.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,50 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/classpath.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<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">
|
||||
<ivysettings>
|
||||
<classpath file="${ivy.settings.dir}/custom-resolver.jar"/>
|
||||
<typedef name="custom" classname="org.apache.ivy.resolver.CustomResolver"/>
|
||||
<resolvers>
|
||||
<custom name="custom"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
Adds custom-resolver.jar found in the same directory as the ivysettings.xml file itself to the classpath, then define a custom resolver and use it.
|
||||
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<classpath url="http://www.myserver.com/ivy/custom-resolver.jar"/>
|
||||
<typedef name="custom" classname="org.apache.ivy.resolver.CustomResolver"/>
|
||||
<resolvers>
|
||||
<custom name="custom"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
Same as above, but find the jar on a web server.
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/classpath.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,58 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/settings.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> settings
|
||||
|
||||
Configures some important ivy info: default resolver, latest strategy, conflict manager...
|
||||
|
||||
Default resolver is used whenever nothing else is configured in the modules section of the settings file. It should give the name of a dependency resolver defined in the [[configuration/resolvers]] section of the settings file.
|
||||
|
||||
Default latest strategy and conflict manager can also be configured here.
|
||||
|
||||
<em>validate</em> indicates if ivy files should generally be validated against the xsd or not. This setting is only a default value, and can be overridden:
|
||||
1) in ant tasks
|
||||
2) in resolvers
|
||||
So if there is a setting in the resolver, it always wins against all other settings.
|
||||
|
||||
<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>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="../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>defaultResolveMode</td><td>the default [[ant:resolve resolve mode]] to use for all modules, except if they have a <a href="../configuration/module.html"> module specific resolve mode setting</a>. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to 'default'</td></tr>
|
||||
<tr><td><a name="circularDependencyStrategy"></a>circularDependencyStrategy</td><td>the name of the <a href="../concept.html#circular">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>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>
|
||||
<tr><td><s>defaultCache</s></td><td>a path to a directory to use as default basedir for both resolution and repository cache(s).
|
||||
<i>Deprecated, we recommend using defaultCacheDir on the [[configuration/caches]] tag instead</i></td>
|
||||
<td>No, defaults to .ivy2/cache in user home</td></tr>
|
||||
<tr><td><s>checkUpToDate</s></td><td>Indicates if date should be checked before retrieving artifacts from cache.
|
||||
<i>Deprecated, we recommend using checkUpToDate on the [[configuration/caches]] tag instead</i></td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
<tr><td><s>cacheIvyPattern</s></td><td>a pattern to indicate where ivy files should be put in cache.
|
||||
<i>Deprecated, we recommend using ivyPattern on the [[configuration/caches]] tag instead</i></td>
|
||||
<td>No, defaults to [organisation]/[module]/ivy-[revision].xml</td></tr>
|
||||
<tr><td><s>cacheArtifactPattern</s></td><td>a pattern to indicate where artifact files should be put in cache.
|
||||
<i>Deprecated, we recommend using artifactPattern on the [[configuration/caches]] tag instead</i></td>
|
||||
<td>No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/settings.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,46 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/conflict-managers.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> conflict-managers
|
||||
|
||||
Defines a list of <a href="../concept.html#conflict">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>latest-compatible</li> this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end this conflict manager does not allow any conflict (like the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
|
||||
<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="../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>compatible-cm</li>The latest compatible conflict manager uses a latest strategy to select the latest revision among several ones. It takes 'latest' as attribute to define which latest strategy should be used. Example:
|
||||
<code><compatible-cm name="my-latest-compatible-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 id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/conflict-managers.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,55 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/include.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> include
|
||||
|
||||
Includes another ivysettings file as if it were part of this one. <span class="since">since 1.3</span>
|
||||
|
||||
The included ivysettings file has to be a complete well formed ivysettings file, i.e. it does have to include the <code><ivysettings></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 ivysettings file to include</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<property name="myrepository" value="path/to/my/real/rep"/>
|
||||
<settings defaultResolver="default"/>
|
||||
<include file="path/to/ivysettings-default.xml"/>
|
||||
</ivysettings>
|
||||
</code>
|
||||
with ivysettings-default.xml:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<property name="myrepository" value="path/to/rep" overwrite="false"/>
|
||||
<resolvers>
|
||||
<ivyrep name="default" ivyroot="${myrepository}"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
The included ivysettings 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 override the value given in the main ivysettings including this one, so the value used for myrepository will be path/to/my/real/rep.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<include file="ivysettings-macro.xml"/>
|
||||
<resolvers>
|
||||
<mymacro name="includeworks" mymainrep="included/myrep" mysecondrep="included/secondrep"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
with ivysettings-macro.xml being the ivysettings example given on the <a href="../configuration/macrodef.html">macrodef documentation page</a>.
|
||||
This let reusing macro resolver easy.
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/include.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,69 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/latest-strategies.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> latest-strategies
|
||||
|
||||
Defines a list of <a href="../concept.html#latest">latest strategies</a> usable in ivy. Each latest strategy is identified by its name, given as an attribute.
|
||||
The child tag used for the latest strategy must be equal to a name of a latest strategy type (usually added with the typedef tag).
|
||||
|
||||
The latest strategies which are always included in ivy (and do not require anything in the configuration file) are:
|
||||
<ul>
|
||||
<li>latest-time</li> 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> 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> compares the revisions as string, using lexicographic order (the one used by java string comparison).
|
||||
</ul>
|
||||
|
||||
<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 latest strategy</td><td>adds a latest strategy to the list of available strategies</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>latest-revision</h1>
|
||||
<span class="since">since 1.4</span> The latest-revision can now be configured to handle more words with special meanings than the one defined in php version_compare function.
|
||||
|
||||
Here is an example of how you can do so:
|
||||
<code type="xml">
|
||||
<latest-strategies>
|
||||
<latest-revision name="mylatest-revision">
|
||||
<specialMeaning name="PRE" value="-2"/>
|
||||
<specialMeaning name="QA" value="4"/>
|
||||
<specialMeaning name="PROD" value="5"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</code>
|
||||
Knowing that the default special meaning words are the following:
|
||||
<code type="xml">
|
||||
<specialMeaning name="dev" value="-1"/>
|
||||
<specialMeaning name="rc" value="1"/>
|
||||
<specialMeaning name="final" value="2"/>
|
||||
</code>
|
||||
You can even get rid or redefine the default special meanings by setting usedefaultspecialmeanings="false" on the latest-revision tag.
|
||||
Example:
|
||||
<code type="xml">
|
||||
<latest-strategies>
|
||||
<latest-revision name="mylatest-revision" usedefaultspecialmeanings="false">
|
||||
<specialMeaning name="pre" value="-2"/>
|
||||
<specialMeaning name="m" value="1"/>
|
||||
<specialMeaning name="rc" value="2"/>
|
||||
<specialMeaning name="prod" value="3"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</code>
|
||||
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/latest-strategies.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,41 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/lock-strategies.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> lock-strategies <span class="since">since 2.0</span>
|
||||
|
||||
Defines a list of lock strategies usable in Ivy.
|
||||
|
||||
A lock strategy is used by a cache manager to decide when and how locking should be performed (see [[configuration/cache]] to see how to configure the lock strategy to use).
|
||||
|
||||
Two lock strategies are registered by default:
|
||||
<ul>
|
||||
<li><b>no-lock</b></li> This lock strategy actually performs no locking at all, and thus should not be used in environment where the cache is shared by multiple processes.
|
||||
|
||||
This strategy is implemented by ([[svn:src/java/org/apache/ivy/plugins/lock/NoLockStrategy.java NoLockStrategy]])
|
||||
|
||||
|
||||
<li><b>artifact-lock</b></li> This strategy acquire a lock whenever a module descriptor or an artifact is downloaded to the cache, which makes a good solution when you want to share your repository cache.
|
||||
|
||||
Note that this strategy is based on file locking, performed by default using the java.io.File.createNewFile() atomicity (which is documented as atomic in the javadoc, but not recommended to perform locks). A java.nio.FileLock based implementation is also provided, but according to our tests the createNewFile based one performs better and more reliably. We heavily recommend making your own testing in your target environment before relying on this lock strategy for heavily concurrent operations.
|
||||
|
||||
This strategy is implemented by ([[svn:src/java/org/apache/ivy/plugins/lock/ArtifactLockStrategy.java ArtifactLockStrategy]])
|
||||
</ul>
|
||||
|
||||
The child tag used for the lock strategy must be equal to a name of a lock strategy type (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 lock strategy</td><td>adds a lock strategy to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table></textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/lockstrategies.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,130 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/macrodef.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> macrodef
|
||||
|
||||
Defines a new dependency resolver type based upon an other one. This definition is very similar to the macrodef feature of ant for defining macro tasks. <span class="since">since 1.3</span>
|
||||
|
||||
This task eases the lot the process of creating new dependency resolver, because it avoid writing java code.
|
||||
|
||||
It is generally used in combination with the <a href="../configuration/include.html">include</a> feature to help reusing macro at several places.
|
||||
|
||||
A macro is defined by writing the resolver it is equivalent to as if it were written in the resolver place, except that you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name and sometimes a default value, and are used using the following syntax:
|
||||
<code>@{attributename}</code>
|
||||
<h2>Resolvers names</h2>
|
||||
Since you can use the same macro several times, and that your macro may define several resolvers (in a chain for instance), resolvers names need to be chosen carefully to avoid name conflicts (a resolver must have a unique name).
|
||||
|
||||
Therefore here is how Ivy deals with the names of the resolvers defined in a macro:
|
||||
<ul>
|
||||
<li>if there is no name attribute on a resolver in the macrodef, then Ivy will use the name given when using the macro. This is what usually should be done for the main resolver defined in the macro</li>
|
||||
<li>if there is a name attribute on a resolver in the macrodef, but this name doesn't contain a @{name} inside, then Ivy will use the provided name prefixed with the name of the macro separated by a dash</li>
|
||||
<li>if there is a name attribute on a resolver in the macrodef, and this name contains @{name} somewhere, then Ivy will use this name, and replace @{name} with the name provided when using the macro.
|
||||
</ul>
|
||||
|
||||
Example:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<macrodef name="mymacro">
|
||||
<chain>
|
||||
<ibiblio name="ex1" />
|
||||
<ibiblio name="ex2.@{name}" m2compatible="true" />
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" />
|
||||
<mymacro name="other" />
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
This is equivalent to:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<resolvers>
|
||||
<chain name="default">
|
||||
<ibiblio name="default-ex1" />
|
||||
<ibiblio name="ex2.default" m2compatible="true" />
|
||||
</chain>
|
||||
<chain name="other">
|
||||
<ibiblio name="other-ex1" />
|
||||
<ibiblio name="ex2.other" m2compatible="true" />
|
||||
</chain>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
<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>name</td><td>name of the resover type created</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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><a href="../configuration/macrodef/attribute.html">attribute</a></td><td>defines an attribute for the macro resolver</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td>any resolver</td><td>defines the base resolver upon which this macro is defined</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
Defining a simple macro:
|
||||
<code type="xml">
|
||||
<macrodef name="mymacro">
|
||||
<attribute name="mymainrep"/>
|
||||
<filesystem name="fs1">
|
||||
<ivy pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
<artifact pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
</macrodef>
|
||||
</code>
|
||||
Using it:
|
||||
<code type="xml">
|
||||
<resolvers>
|
||||
<mymacro name="default" mymainrep="path/to/myrep"/>
|
||||
</resolvers>
|
||||
</code>
|
||||
<hr/>
|
||||
A complete example:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<macrodef name="mymacro">
|
||||
<attribute name="mymainrep"/>
|
||||
<attribute name="mysecondrep"/>
|
||||
<attribute name="myseconddirlayout" default="[organisation]/[module]/[type]s"/>
|
||||
<chain>
|
||||
<filesystem name="fs1">
|
||||
<ivy pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
<artifact pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
<filesystem name="fs2" latest="latest-time">
|
||||
<ivy pattern="@{mysecondrep}/@{myseconddirlayout}/ivy-[revision].xml"/>
|
||||
<artifact pattern="@{mysecondrep}/@{myseconddirlayout}/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" mymainrep="path/to/myrep" mysecondrep="path/to/secondrep"/>
|
||||
<mymacro name="other"
|
||||
mymainrep="path/to/myrep"
|
||||
mysecondrep="path/to/secondrep"
|
||||
myseconddirlayout="[module]/[type]s"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/macrodef.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,27 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/macrodef/attribute.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> attribute
|
||||
|
||||
Defines a macrodef attribute. See macrodef for details.
|
||||
<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>name</td><td>the name of the attribute</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>default</td><td>the default value of the attribute if none is specified</td>
|
||||
<td>No, by default attribute are required</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/macrodef/attribute.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,89 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/module.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> module
|
||||
|
||||
Define a module set rule. The tag defines a module set, by giving an expression and the matcher to use for organisation, name, revision and any extra attribute identifying your modules. The rule matching is performed in order, and is using a pattern matcher. Hence you can use * to specify all, or simply avoid specifying the attribute.
|
||||
|
||||
The revision and extra attributes are only used for rules defining the resolver to use. For other settings, use only organisation and module name.
|
||||
|
||||
It also gives the specific setting to use for this module set.
|
||||
|
||||
For each module set, you can configure:
|
||||
<ul>
|
||||
<li>the <a href="../configuration/resolvers.html">resolver</a> to use</li>
|
||||
<li>the <a href="../configuration/conflict-managers.html">conflict manager</a> to use</li>
|
||||
<li>the default <a href="../terminology.html#branch">branch</a> to use</li>
|
||||
<li>the [[ant:resolve resolve mode]] to use</li>
|
||||
</ul>
|
||||
|
||||
<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>organisation</td><td>the organisation to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>name</td><td>the module's name to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>revision</td><td>the module's revision to match to apply the rule. Note that the version may not be resolved yet (be latest.integration for instance), so be very careful when using this attribute. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td><em>any extra attribute</em></td><td>an extra attribute to match to apply the rule. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>matcher</td><td>the <a href="../concept.html#matcher">matcher</a> to use to match the modules to which the resolver should be applied <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to exactOrRegexp</td></tr>
|
||||
<tr><td>resolver</td><td>the name of the resolver to apply. The resolver must have been defined in the resolvers section of the configuration file.</td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>conflict-manager</td><td>the name of the conflict manager to apply. <span class="since">since 1.4</span></td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>branch</td><td>the default branch to apply. <span class="since">since 1.4</span></td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>resolveMode</td><td>the resolve mode to use. <span class="since">since 2.0</span></td>
|
||||
<td>No</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="*" resolver="myprojectsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myprojectresolver for all modules from Apache.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="commons-*" matcher="glob" resolver="myapachecommonsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myapachecommonsresolver for all modules beginning by commons- from apache.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="commons-[a-z]+" myextra="val.*" matcher="regexp" resolver="myapachecommonsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myapachecommonsresolver for all modules from 'apache' beginning by 'commons-' followed by any number of alphabetic lowercase characters, and with the extra attribute 'myextra' having a value starting with 'val'.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" conflict-manager="latest-time"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses latest-time conflict manager for all modules from apache which name begins with ivy.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" branch="fix-103"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses 'fix-103' as default branch for all modules from apache which name begins with ivy.
|
||||
|
||||
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/module.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,30 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/modules.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> modules
|
||||
|
||||
Defines per module or module set settings.
|
||||
|
||||
The rules are given by defining a module set, using pattern for module organisation and name, and giving some settings for the set, like the name of the corresponding resolver to use.
|
||||
|
||||
If no rule match a given module, the default setting will be used.
|
||||
|
||||
Even if not required, because the use of a default big resolver (chain, for instance) able to resolve all dependencies can answer all the needs, the configuration of smaller resolvers used for different cases can improve performances a lot. For instance, if you have a local repository for your modules and a distant repository for third party libraries, it is a good idea to have two separate resolvers, and configure ivy to use one for all your modules and another for the rest (the default one).
|
||||
|
||||
<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><a href="../configuration/module.html">module</a></td><td>defines a module set rule</td>
|
||||
<td>1..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/modules.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,106 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/namespace.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> namespace
|
||||
|
||||
Defines a new namespace. A namespace is identified by a name, which is used to reference the namespace in the resolvers using the namespace.
|
||||
|
||||
Namespaces overview is given in the <a href="../configuration/namespaces.html">namespaces</a> documentation.
|
||||
|
||||
A namespace mainly consists of a list of rules, each rule defining a translation between system namespace and the defined namespace, and vice versa.
|
||||
|
||||
There are two main possibilities for using these rules. By default, a namespace iterate through the rules, and when it finds one that translate the given name, it returns the translated name. But the namespace can be configured to do use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.
|
||||
<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>name</td><td>the namespace name</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>chainrules</td><td>true to indicate that namespaces rules should be chained, false otherwise</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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><a href="../configuration/namespace/rule.html">rule</a></td><td>defines a new namespace rule</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Example</h1>
|
||||
<code type="xml">
|
||||
<namespace name="test">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg"/>
|
||||
<dest org="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="A"/>
|
||||
<dest org="systemorg"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
<code type="xml">
|
||||
<namespace name="test">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg2" module="system\-(.+)"/>
|
||||
<dest org="B" module="$m1"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="B" module=".+"/>
|
||||
<dest org="systemorg2" module="system-$m0"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
<code type="xml">
|
||||
<namespace name="test" chainrules="true">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg"/>
|
||||
<dest org="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="A"/>
|
||||
<dest org="systemorg"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src module="systemmod"/>
|
||||
<dest module="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src module="A"/>
|
||||
<dest module="systemmod"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src module="systemmod2"/>
|
||||
<dest module="B"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src module="B"/>
|
||||
<dest module="systemmod2"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/namespace.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,42 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/namespace/dest.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> dest
|
||||
|
||||
Defines the translation part of a translation rule. If a name has matched a corresponding src, it will be translated using this dest part.
|
||||
|
||||
The new names can contain references to groups of the matched name, using a slightly modified regexp syntax. Indeed, referenced groups can be part of either the organisation, module or revision part of the original name. So, to reference the groups, you just have to add a letter identifying the part in which the group should be selected: o for organisation, m for module, and r for revision.
|
||||
|
||||
For instance, $o0 matches the whole matched organisation, and $m0 the whole matched module name. $o1 matches the first group of the matched organisation.
|
||||
|
||||
For details about regexp and groups, see the <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html">Pattern class documentation</a> in the jdk.
|
||||
<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>org</td><td>the new organisation name</td>
|
||||
<td>No, defaults to $o0</td></tr>
|
||||
<tr><td>module</td><td>the new module name</td>
|
||||
<td>No, defaults to $m0</td></tr>
|
||||
<tr><td>rev</td><td>the new revision</td>
|
||||
<td>No, defaults to $r0</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<fromsystem>
|
||||
<src org="systemorg2" module="system\-(.+)"/>
|
||||
<dest org="B" module="$m1"/>
|
||||
</fromsystem>
|
||||
</code>
|
||||
Matches modules from systemorg2 which have a name beginning with system followed by a minus and anything else, and translate it to organisation B and module the part following <code>system-</code> of the original name.
|
||||
|
||||
</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/namespace/dest.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,26 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/namespace/fromtosystem.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> fromsystem / tosystem
|
||||
|
||||
Defines a one way translation rule, i.e. a translation from system namespace to the defined namespace or vice versa.
|
||||
<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><a href="../../configuration/namespace/src.html">src</a></td><td>defines a source name which can be accepted</td>
|
||||
<td>1..n</td></tr>
|
||||
<tr><td><a href="../../configuration/namespace/dest.html">dest</a></td><td>defines the translation to apply when a name is accepted by an src pattern</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/namespace/fromtosystem.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,28 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/namespace/rule.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> rule
|
||||
|
||||
Defines a new namespace rule. A rule defines a translation between system namespace and the defined namespace, and vice versa.
|
||||
|
||||
See <a href="../../configuration/namespace.html">namespace</a> doc for details.
|
||||
|
||||
<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><a href="../../configuration/namespace/fromtosystem.html">fromsystem</a></td><td>defines the translation to apply from system namespace to the defined namespace</td>
|
||||
<td>1</td></tr>
|
||||
<tr><td><a href="../../configuration/namespace/fromtosystem.html">tosystem</a></td><td>defines the translation to apply from the defined namespace to system namespace</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/namespace/rule.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,28 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../../settings/namespace/src.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> src
|
||||
|
||||
Defines the acceptation part of a translation rule. If a name matches this src, it will be translated using the dest part.
|
||||
<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>org</td><td>the organisation to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
<tr><td>module</td><td>the module name to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
<tr><td>rev</td><td>the revision to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../../settings/namespace/src.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,37 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/namespaces.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> namespaces
|
||||
|
||||
Namespaces are an advanced feature of Ivy which let you use resolvers in which module names and organisations are not consistent between each other.
|
||||
|
||||
For instance, if you want to use maven2 repository and ivyrep collectively, you will face some naming issues. For example all apache commons projects are declared to be part of the organisation apache in ivyrep whereas in maven2 ibiblio repository, they are declared to be part of the organisation of the same name of the module.
|
||||
|
||||
So if you try to use both maven2 and ivyrep repositories, you will face some issues like:
|
||||
<quote>
|
||||
How do I declare a dependency on commons-lang ?
|
||||
I have an error while trying to resolve module xxx. It says that it depends on [commons-httpclient commons-httpclient] ant that it isn't available.
|
||||
...
|
||||
</quote>
|
||||
|
||||
Ivy has an answer to give to this kind of troubles, and this answer is called namespaces. In short, you can affect a namespace to each dependency resolver in Ivy, and each namespace defines rules to convert names from the system namespace to the defined namespace itself, and vice versa.
|
||||
|
||||
This very powerful feature is thoroughly used in the <a href="../tutorial/build-repository/advanced1.html">build your own repository tutorial</a>, and this is a good place to have examples of what can be done with namespaces.
|
||||
|
||||
<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><a href="../configuration/namespace.html">namespace</a></td><td>defines a new namespace</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/namespaces.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,44 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/outputters.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> outputters
|
||||
|
||||
Defines a list of report outputters usable in ivy.
|
||||
|
||||
A report outputter is used at the end of the resolve process to generate a report of how the resolve has been performed.
|
||||
|
||||
Two report outputters are registered by default:
|
||||
<ul>
|
||||
<li>a log report outputter ([[svn:src/java/org/apache/ivy/plugins/report/LogReportOutputter.java LogReportOutputter]])</li>which produces the output on the console at the end of the resolve, which looks like this:
|
||||
<code>
|
||||
---------------------------------------------------------------------
|
||||
| | modules || artifacts |
|
||||
| conf | number| search|dwnlded|evicted|| number|dwnlded|
|
||||
---------------------------------------------------------------------
|
||||
| default | 1 | 1 | 0 | 0 || 1 | 1 |
|
||||
---------------------------------------------------------------------
|
||||
</code>
|
||||
<li>an xml report outputter ([[svn:src/java/org/apache/ivy/plugins/report/XmlReportOutputter.java XmlReportOutputter]])</li>which produces an xml report in the cache, which is mandatory for correct Ivy behaviour, since it's that report which is used when you do a post resolve step in a separate buid from the resolve itself. It's also this xml report which is processed to generate all the different reports available in the [[ant:report]] task.
|
||||
</ul>
|
||||
|
||||
The child tag used for the parser must be equal to a name of a report outputter type (added with the typedef tag).
|
||||
|
||||
To see how to define your own report outputter see <a href="../extend.html">Extending Ivy documentation</a>
|
||||
|
||||
<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 report outputter</td><td>adds a report outputter to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/outputters.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,32 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/parsers.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> parsers
|
||||
|
||||
Defines a list of module descriptor parsers usable in ivy. Each parser defines which resources (which descriptor file) it accepts.
|
||||
The child tag used for the parser must be equal to a name of a parser type (added with the typedef tag).
|
||||
|
||||
Note that when looking for a parser, ivy queries the parsers list in the reverse order. So the last parser in the list will be queried first. Consequently, if the last parser accepts all resources, the other parsers will never have a chance to parse the resource.
|
||||
|
||||
Two parsers are available by default and thus do not need to be declared in this section:
|
||||
<ul>
|
||||
<li>ivy file parser</li> this is the parser used for ivy xml files. This parser is used for resources that aren't accepted by any other parser.
|
||||
<li>pom parser</li>this parser is able to parse maven2 pom files
|
||||
</ul>
|
||||
<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 module descriptor parser</td><td>adds a module descriptor parser to the list of available parsers</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/parsers.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,30 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/properties.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> properties<br/>
|
||||
<br/>
|
||||
Loads a properties file into ivy variables. See variables chapter above for details about ivy variables.
|
||||
|
||||
<span class="since">Since 2.0</span>: it is possible to access environment variables. This can be done by specifying the environment attribute. This attribute specifies the prefix which can be used to access these environment variables. For instance, if you specify environment="env", you can access the PATH environment variable with the env.PATH property name.
|
||||
|
||||
<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 a properties file to load</td>
|
||||
<td rowspan="2">One of these</td></tr>
|
||||
<tr><td>environment</td><td>the prefix to use when retrieving environment variables <span class="since">(since 2.0)</span></td>
|
||||
<tr><td>override</td><td>indicates if the variable found in the properties file should override their previous value, if any <span class="since">(since 1.3)</span></td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/properties.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,40 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/property.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> property
|
||||
|
||||
Defines an ivy variable. <span class="since">since 1.3</span>
|
||||
|
||||
The optional override attribute enables to avoid overriding the previous value of the varable, which makes the definition behave like ant properties, which is particularly useful to define default values (values which are used only if they haven't been defined yet).
|
||||
<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>name</td><td>the name of the variable to define</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>value</td><td>the new value the variable must take</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>override</td><td>true if the previous value (if any) of the variable should overriden, false otherwise</td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<property name="myvar" value="myvalue"/>
|
||||
</code>
|
||||
Sets the variable myvar to the value myvalue.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<property name="myvar" value="myvalue" override="false"/>
|
||||
</code>
|
||||
Sets the variable myvar to the value myvalue only if myvar has not been set yet.
|
||||
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/property.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,175 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/resolvers.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> resolvers
|
||||
|
||||
Defines a list of dependency resolvers usable in ivy. Each dependency resolver is identified by its name, given as an attribute.
|
||||
|
||||
The child tag used for the dependency resolver must be equal to a name of a dependency resolver type (either built-in or added with the typedef tag).
|
||||
|
||||
<span class="since">since 1.3</span> Once defined, resolvers can be referenced by their name, using the following syntax:
|
||||
<code type="xml">
|
||||
<resolver ref="alreadydefinedresolver"/>
|
||||
</code>
|
||||
Note that this works only if the resolver has been already defined, and not if it is defined later in the ivysettings file.
|
||||
<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 resolver</td><td>adds a resolver to the list of available resolvers</td>
|
||||
<td>1..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Built-in Resolvers</h1>
|
||||
Ivy comes with a set of built-in dependency resolvers able to answer to the most common needs.
|
||||
|
||||
If you don't find the one you want here, you can also check if some one has not contributed it in the [[links links page]], or even <a href="../extend.html">write your own</a>.
|
||||
|
||||
There are basically two types of resolver in Ivy: composite and standard resolvers. A composite resolver is a resolver which delegates the work to other resolvers. The other resolvers are standard resolvers.
|
||||
|
||||
Here is the list of built-in resolvers:
|
||||
|
||||
<table class="ivy-attributes">
|
||||
<thead>
|
||||
<tr><th>Name</th><th>Type</th><th>Description</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><a href="../resolver/ivyrep.html">IvyRep</a></td><td>Standard</td><td>Finds ivy files on ivyrep and artifacts on ibiblio.</td></tr>
|
||||
<tr><td><a href="../resolver/ibiblio.html">IBiblio</a></td><td>Standard</td><td>Finds artifacts on ibiblio.</td></tr>
|
||||
<tr><td><a href="../resolver/packager.html">Packager</a></td><td>Standard</td><td>Finds ivy files and packaging instructions via URLs, then creates artifacts by following the instructions.</td></tr>
|
||||
<tr><td><a href="../resolver/filesystem.html">FileSystem</a></td><td>Standard</td><td>This very performant resolver finds ivy files and artifacts in your file system.</td></tr>
|
||||
<tr><td><a href="../resolver/url.html">Url</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with urls.</td></tr>
|
||||
<tr><td><a href="../resolver/vfs.html">Vfs</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with <a href="http://jakarta.apache.org/commons/vfs/">apache commons vfs</a>.</td></tr>
|
||||
<tr><td><a href="../resolver/ssh.html">ssh</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with ssh.</td></tr>
|
||||
<tr><td><a href="../resolver/sftp.html">sftp</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with sftp.</td></tr>
|
||||
<tr><td><a href="../resolver/chain.html">Chain</a></td><td>Composite</td><td>Delegates the finding to a chain of sub resolvers.</td></tr>
|
||||
<tr><td><a href="../resolver/dual.html">Dual</a></td><td>Composite</td><td>Delegates the finding of ivy files to one resolver and of artifacts to another.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1><a name="common">Common features and attributes</a></h1>
|
||||
All resolvers of the same type share some common features and attributes detailed here.
|
||||
<h2>Features</h2>
|
||||
<h3>validation</h3>
|
||||
All standard resolvers support several options for validation.
|
||||
|
||||
The validate attribute is used to configure if Ivy files should be checked against the Ivy file xml schema.
|
||||
|
||||
The checkconsistency attribute allow to enable or disable consistency checking between what is expected by Ivy when it finds a module descriptor, and what the module descriptor actually contains.
|
||||
|
||||
The descriptor attribute let one define if module descriptors are mandatory or optional.
|
||||
|
||||
The checksums attribute is used to define the list of checksums files to use to check the content of downloaded files has not been corrupted (eg during transfer).
|
||||
<h3>force</h3>
|
||||
Any standard resolver can be used in force mode, which is used mainly to handle local development builds. In force mode, the resolver attempts to find a dependency whatever the requested revision is (internally it replace the requested revision by 'latest.integration'), and if it finds one, it forces this revision to be returned, even when used in a chain with returnFirst=false.
|
||||
|
||||
By using such a resolver at the beginning of a chain, you can be sure that Ivy will pick up whatever module is available in this resolver (usually a private local build) instead of the real requested revision. This allows to handle use case like a developer working on modules A and C, where A -> B -> C, and pick up the local build for C without having to publish a local version of B.
|
||||
<span class="since">since 2.0</span>
|
||||
|
||||
<h2>Attributes</h2>
|
||||
<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><th>Composite</th><th>Standard</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>name</td><td>the name which identify the resolver</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>validate</td><td>indicates if resolved ivy files should be validated against ivy xsd</td>
|
||||
<td>No, defaults to call setting</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>force</td><td>Indicates if this resolver should be used in force mode (see above). <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to false</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checkmodified</td><td>Indicates if this resolver should check lastmodified date to know if an ivy file is up to date.</td>
|
||||
<td>No, defaults to ${ivy.resolver.default.check.modified}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>changingPattern</td><td>Indicates for which revision pattern this resolver should check lastmodified date to know if an artifact file is up to date. <span class="since">since 1.4</span>. See <a href="../concept.html#change">cache and change management</a> for details.</td>
|
||||
<td>No, defaults to none</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>changingMatcher</td><td>The name of the <a href="../concept.html#matcher">pattern matcher</a> to use to match a revision against the configured changingPattern. <span class="since">since 1.4</span>. See <a href="../concept.html#change">cache and change management</a> for details.</td>
|
||||
<td>No, defaults to exactOrRegexp</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>alwaysCheckExactRevision</td><td>Indicates if this resolver should check the given revision even if it's a special one (like latest.integration). <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to ${ivy.default.always.check.exact.revision}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>namespace</td><td>The name of the namespace to which this resolver belong <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to 'system'</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checkconsistency</td><td>true to check consistency of module descriptors found by this resolver, false to avoid consistency check <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to true</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>descriptor</td><td>'optional' if a module descriptor (usually an ivy file) is optional for this resolver, 'required' to refuse modules without module descriptor <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to 'optional'</td>
|
||||
<td>No (except dual)</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>allownomd</td><td><em>DEPRECATED. Use descriptor="required | optional" instead.</em>
|
||||
true if the absence of module descriptor (usually an ivy file) is authorised for this resolver, false to refuse modules without module descriptor <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to true</td>
|
||||
<td>No (except dual)</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checksums</td><td>a comma separated list of <a href="../concept.html#checksum">checksum algorithms</a> to use both for publication and checking <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to ${ivy.checksums}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>latest</td><td>The name of the latest strategy to use.</td>
|
||||
<td>No, defaults to 'default'</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>cache</td><td>The name of the cache manager to use.</td>
|
||||
<td>No, defaults to the value of the default attribute of caches</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<resolvers>
|
||||
<filesystem name="1" cache="cache-1">
|
||||
<ivy pattern="${ivy.settings.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
|
||||
<artifact pattern="${ivy.settings.dir}/1/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
<chain name="chain1">
|
||||
<resolver ref="1"/>
|
||||
<ivyrep name="ivyrep"/>
|
||||
</chain>
|
||||
<chain name="chain2" returnFirst="true" dual="true">
|
||||
<resolver ref="1"/>
|
||||
<ibiblio name="ibiblio"/>
|
||||
</chain>
|
||||
</resolvers>
|
||||
</code>
|
||||
Defines a filesystem resolver, named '1', which is then used in two chains, the first which seconds the filesystem resolver with an ivyrep resolver, and second which seconds the filesystem resolver with an ibiblio resolver, and which returns the first module found, and uses the whole chain to download artifacts (see corresponding resolvers documentation for details about them). Resolver 1 will use a cache named 'cache-1' which should have been defined under the caches element.
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/resolvers.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,27 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/status.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> status
|
||||
|
||||
Define one available module status.
|
||||
|
||||
See <a href="../configuration/statuses.html">statuses</a> page for details about how statuses are defined.
|
||||
|
||||
<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>name</td><td>name of status defined</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>integration</td><td>true if this is an integration status, false otherwise</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/status.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,51 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/statuses.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> statuses
|
||||
|
||||
Defines the list of available statuses. <span class="since">since 1.4</span>
|
||||
|
||||
By default, ivy has 3 statuses: release, milestone and integration. By adding a statuses section to your ivysettings file, you define the statuses you want to use. Note that in this case if you still want to have ivy default statuses you will have to declare them.
|
||||
|
||||
The integration property on each status is only used for recursive delivery, an integration dependency being delivered if the caller is not in integration state itself.
|
||||
|
||||
The default status is the one used when none is defined in a module descriptor. If not specified, it defaults to the last defined status.
|
||||
|
||||
The statuses order is important, the first is considered the more mature, the last the less mature. This is used to know if a status is compatible with a latest.<status> version matcher.
|
||||
|
||||
<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>default</td><td>the name of the status to use when none is declared in an ivy file</td>
|
||||
<td>No, defaults to the last status declared</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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><a href="../configuration/status.html">status</a></td><td>defines a new status</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<statuses default="bronze">
|
||||
<status name="gold" integration="false"/>
|
||||
<status name="silver" integration="false"/>
|
||||
<status name="bronze" integration="true"/>
|
||||
</statuses>
|
||||
</code>
|
||||
Defines 3 statuses, gold, silver and bronze. The default status used when none is declared in an ivy file will be bronze.
|
||||
It is also considered as an integration status, and thus doesn't trigger any recrusive delivery.
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/statuses.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,290 +22,13 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/triggers.html">
|
||||
</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="../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 at the beginning of the resolve process, before a module dependencies and transitive dependencies are 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>req-revision</li>the requested revision for the dependency <span class="since">since 2.0</span> (provided for consistency with post-resolve-dependency)
|
||||
<li>req-revision-default</li>the default requested revision constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-dynamic</li>the requested revision dynamic constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>revision</li>the requested revision 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 this case resolved means resolving the actual revision if the requested revision is a version constraint and not a static version, and downloading all necessary metadata information.</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>req-revision</li>the requested revision for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-default</li>the default requested revision constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-dynamic</li>the requested revision dynamic constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>revision</li>the revision of the dependency resolved, or the requested revision if the resolution was not successful
|
||||
<li>resolved</li>true if the resolution was successful, false otherwise
|
||||
<li>duration</li>the time elapsed to resolve the dependency (in ms) <span class="since">since 2.0</span>
|
||||
<li>resolver</li>the name of the resolver used to resolve the dependency
|
||||
<li>any extra attribute</li>all extra attributes found on the info tag of the resolved dependency are available <span class="since">since 2.0</span>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired after each dependency is resolved</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
|
||||
<li>resolve-id</li>the identifier of the resolution process <span class="since">since 2.0</span>
|
||||
<li>nb-dependencies</li>total number of dependencies, including transitive and evicted ones <span class="since">since 2.0</span>
|
||||
<li>nb-artifacts</li>total number of artifacts resolved, excluding metadata artifacts <span class="since">since 2.0</span>
|
||||
<li>resolve-duration</li>the time (in ms) elapsed to resolve dependencies, before dowloading artifacts <span class="since">since 2.0</span>
|
||||
<li>download-duration</li>the time (in ms) elapsed to download all artifacts, excluding metadata artifacts downloaded during the first phase of the resolution process <span class="since">since 2.0</span>
|
||||
<li>download-size</li>the total size (in bytes) of all downloaded artifacts, excluding metadata artifacts. Only artifacts actually downloaded (not in cache or used from their original location) are considered <span class="since">since 2.0</span>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the end of the resolve process, when all module dependencies have 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>metadata</li>true if the artifact to be downloaded is a metadata artifact, false for published artifacts <span class="since">since 2.0</span>
|
||||
<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>metadata</li>true if the downloaded artifact is a metadata artifact, false for published artifacts <span class="since">since 2.0</span>
|
||||
<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>duration</li>the time elapsed to download the artifact (in ms) <span class="since">since 2.0</span>
|
||||
<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>
|
||||
<tr><td>pre-retrieve <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the module for which the dependencies will be retrieved
|
||||
<li>module</li>the name of the module for which the dependencies will be retrieved
|
||||
<li>revision</li>the revision of the module for which the dependencies will be retrieved
|
||||
<li>conf</li>comma separated list of configurations which will be retrieved
|
||||
<li>symlink</li>true if Ivy will use symbolic links instead of copies on supported platforms, false otherwise
|
||||
<li>sync</li>true if the retrieve process will be performed in sync mode, false otherwise
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the beginning of the retrieve process.</td>
|
||||
</tr>
|
||||
<tr><td>post-retrieve <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the module for which the dependencies have been retrieved
|
||||
<li>module</li>the name of the module for which the dependencies will be retrieved
|
||||
<li>revision</li>the revision of the module for which the dependencies have been retrieved
|
||||
<li>conf</li>comma separated list of configurations which have been retrieved
|
||||
<li>symlink</li>true if Ivy used symbolic links instead of copies on supported platforms, false otherwise
|
||||
<li>sync</li>true if the retrieve process has been performed in sync mode, false otherwise
|
||||
<li>duration</li>the time elapsed in ms during the retrieve process
|
||||
<li>size</li>the total size of artifacts which have actually been copied (or symlinked)
|
||||
<li>nbCopied</li>the number of artifacts copied or symlinked
|
||||
<li>nbUptodate</li>the number of artifacts which were already present and up to date at the destination location
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the end of the retrieve process.</td>
|
||||
</tr>
|
||||
<tr><td>pre-publish-artifact <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the artifact which is about to be published
|
||||
<li>module</li>the name of the module of the artifact which is about to be published
|
||||
<li>revision</li>the revision of the the artifact which is about to be published
|
||||
<li>artifact</li>the name of the the artifact which is about to be published
|
||||
<li>type</li>the type of the the artifact which is about to be published
|
||||
<li>ext</li>the extension of the the artifact which is about to be published
|
||||
<li>resolver</li>the name of the resolver into which the artifact is about to be published
|
||||
<li>file</li>the absolute path of the source file for the artifact
|
||||
<li>overwrite</li>"true" if the new data will overwrite existing artifacts, "false" otherwise
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired before an artifact is published into a repository</td>
|
||||
</tr>
|
||||
<tr><td>post-publish-artifact <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the artifact that was published
|
||||
<li>module</li>the name of the module of the artifact that was published
|
||||
<li>revision</li>the revision of the the artifact that was published
|
||||
<li>artifact</li>the name of the the artifact that was published
|
||||
<li>type</li>the type of the the artifact that was published
|
||||
<li>ext</li>the extension of the the artifact that was published
|
||||
<li>resolver</li>the name of the resolver into which the artifact was published
|
||||
<li>file</li>the absolute path of the source file for the artifact
|
||||
<li>overwrite</li>"true" if the new data overwrote existing artifacts, "false" otherwise
|
||||
<li>status</li>"successful" if the artifact published successfully; "failed" if the artifact failed to publish, or if the status is unknown
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired after an artifact is published into a repository. Note that this event is fired
|
||||
whether or not the publication succeeded. The "status" property can be checked to
|
||||
verify success.</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</td><td>Triggers an ant build.</td></tr>
|
||||
<tr><td>ant-call</td><td>Calls a target in the current ant build.</td></tr>
|
||||
<tr><td>log</td><td>Logs a message on the console or in a log file.</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.settings.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.settings.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>
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<triggers>
|
||||
<log file="ivy.log"
|
||||
message='downloaded "${origin}" to "${file}" (${duration}ms - ${size}B)'
|
||||
event="post-download-artifact" filter="status=successful"/>
|
||||
</triggers>
|
||||
</code>
|
||||
Logs any successful artifact download, with information on the source and destination, and details on download size and duration.
|
||||
|
||||
The file attribute is optional, the log trigger will output messages to console if it isn't provided.</textarea>
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/triggers.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -22,26 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/typedef.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> typedef<br/>
|
||||
<br/>
|
||||
Defines a new type in ivy. Useful to define new dependency resolvers, in particular, but also latest strategies.
|
||||
See <a href="../extend.html">how to write and plug your own dependency resolver</a> for details.
|
||||
<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>name</td><td>the name of the type to define. This name is then used as an xml tag.</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>classname</td><td>the fully qualified class name of the type to define.</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/typedef.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -22,30 +22,12 @@
|
|||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
<meta HTTP-EQUIV="REFRESH" content="3; url=../settings/version-matchers.html">
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> version-matchers
|
||||
|
||||
Defines a list of version matchers. <span class="since">since 1.4</span>
|
||||
|
||||
The child tag used for the version matcher must be equal to a name of a report outputter type (added with the typedef tag).
|
||||
|
||||
A version matcher is used to evaluate if a a dependency version contraint matches a dependency version.
|
||||
|
||||
See <a href="../ivyfile/dependency.html">dependency</a> doc for details about built-in version matchers.
|
||||
|
||||
<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 version matcher</td><td>adds a version matcher to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<textarea id="xooki-source">
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
<a href="../settings/version-matchers.html">here</a>.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ The tutorials is the best way to begin to play with ivy. You will easily and qui
|
|||
<li>[[reference]]</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).
|
||||
It's also in the reference doc that you will find all you always dreamed to know about ivy settings, ivy files, and ivy use (especially with ant).
|
||||
<li>[[dev]]</li>
|
||||
The developers's doc is useful for users who would like to extend Ivy or build it from source. It's also the documentation used by the Ivy team, so you will also find information about how we make releases.
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@
|
|||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> conf <b>Parent:</b> <a href="../ivyfile/configurations.html">configurations</a>
|
||||
<b>Tag:</b> conf <b>Parent:</b> [[ivyfile/configurations]]
|
||||
|
||||
Declares a configuration of this module. As described in the reference page, a 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.
|
||||
Declares a configuration of this module. As described in the reference page, a 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 module configurations.
|
||||
|
||||
The conf element in the configurations section declares one configuration. This declaration gives the name of the configuration declared, its visibility and the other configurations of the module it extends.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
Specify a a conflict manager for one or several dependencies.
|
||||
The way to specify a conflict manager is by giving indication to which dependencies the conflict manager applies (by giving organisation and module names or name regexp), and then specifying the conflict manager, either by giving its name or by specifying a fixed revision list, in which case a fixed conflicts manager is used.
|
||||
|
||||
The list of built-in conflict managers available is listed on the <a href="../configuration/conflict-managers.html">conflict manager configuration page</a>.
|
||||
The list of built-in conflict managers available is listed on the [[settings/conflict-managers conflict manager configuration page]].
|
||||
|
||||
Conflicts manager are used during the resolve operation, i.e. when ivy analyse the graph of dependencies and download corresponding ivy files and artifacts. The fact to manage conflict at resolve time enables to minimize downloads: when a module is evicted by a conflict manager, it is not downloaded.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
Container for conflict manager elements, used to indicate how conflicts should be resolved
|
||||
for this module. <br/><br/>
|
||||
|
||||
The list of built-in conflict managers available is listed on the <a href="../configuration/conflict-managers.html">conflict manager configuration page</a>.<br/><br/>
|
||||
The list of built-in conflict managers available is listed on the [[settings/conflict-managers conflict manager configuration page]].<br/><br/>
|
||||
|
||||
Conflicts manager are used during the resolve operation, i.e. when ivy analyse the graph of dependencies
|
||||
and download corresponding ivy files and artifacts. The fact to manage conflict at resolve time
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ This container let the possibility to define two very similar things: defaultcon
|
|||
|
||||
<code>defaultconf</code> exists since Ivy 1.1 and enables to define the default conf attribute to use when no conf is defined for a dependency in this ivy file. It is only used when no conf mapping is defined, and has no influence in other cases.
|
||||
|
||||
<code>defaultconfmapping</code> exists since Ivy 1.3 and enables not only to define the default conf mapping when no conf is specified for a dependency in this ivy file, but it also influence the way conf mapping with no mapped conf are interpreted (see <a href="../ivyfile/configurations.html">configurations doc page</a> for details about this).
|
||||
<code>defaultconfmapping</code> exists since Ivy 1.3 and enables not only to define the default conf mapping when no conf is specified for a dependency in this ivy file, but it also influence the way conf mapping with no mapped conf are interpreted (see [[ivyfile/configurations configurations doc page]] for details about this).
|
||||
|
||||
Note that if both defaultconf and defaultconfmapping are defined, it's the defaultconfmapping that is used. Note also that if several defaultconfmapping are defined (one in the configurations tag, one or several in included configurations file, and/or one in the dependency tag, then it's only the last which is taken into account, the others will have no effect at all.
|
||||
<h1>Attributes</h1>
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The revision can be given as a fixed one (1.5.2, for instance) or as a latest (o
|
|||
<li>latest.integration</li> selects the latest revision of the dependency module.
|
||||
<li>latest.[any status]</li> selects the latest revision of the dependency module with at least the specified status. <span class="since">since 1.4</span>
|
||||
For instance latest.milestone will select the latest version being either a milestone or a release, and latest.release will only selects the latest release. Note that in order to find the latest revision with the appropriate status Ivy has to parse all the ivy files in your repository from the last one until it finds such a revision. Hence don't be surprised if the resolution slow down.
|
||||
See also [[configuration/statuses]] to see how to configure module statuses.
|
||||
See also [[settings/statuses]] to see how to configure module statuses.
|
||||
<li>end the revision with a +</li> selects the latest sub-revision of the dependency module. For instance,
|
||||
if the dependency module exists in revision 1.0.3, 1.0.7 and 1.1.2, "1.0.+" will select 1.0.7.
|
||||
<li>version ranges</li> mathematical notation for ranges can be used to match a range of version. <span class="since">since 1.4</span>
|
||||
|
|
@ -49,7 +49,7 @@ Examples:
|
|||
(,2.0] matches all versions lower or equal to 2.0
|
||||
(,2.0[ matches all versions lower than 2.0
|
||||
</ul>
|
||||
<span class="since">since 1.4</span> If you don't find a way to expression your dependency version constraint among these, you can <a href="../configuration/version-matchers.html">plug your own</a>.
|
||||
<span class="since">since 1.4</span> If you don't find a way to expression your dependency version constraint among these, you can [[settings/version-matchers plug your own]].
|
||||
The way to determine which revision is the "latest" between two is configurable through the use of pluggable LatestStrategy. See <a href="../reference.html">ivy main concepts</a> for details about this.
|
||||
|
||||
<h2><a name="revision-constraint">Revision constraint</a></h2>
|
||||
|
|
@ -65,11 +65,11 @@ There are several ways to declare this mapping of configurations, choose dependi
|
|||
The first way to declare this mapping is called the inline mapping. It is maybe the less natural at first, but it's powerful and concise. Inline mapping can take several forms.
|
||||
|
||||
<ul>
|
||||
<li>Specify one configuration name</li> This means that in this master configuration the same dependency configuration is needed (except if a defaultconfmapping has been specified in this ivy file, see <a href="../ivyfile/configurations.html">configurations</a> for details, or table below for examples).
|
||||
<li>Specify one configuration name</li> This means that in this master configuration the same dependency configuration is needed (except if a defaultconfmapping has been specified in this ivy file, see [[ivyfile/configurations configurations]] for details, or table below for examples).
|
||||
For instance, if the current module has defined a configuration named 'runtime', and the dependency too, then having an inline mapping configuration set to 'runtime' means that in the runtime master configuration the runtime dependency configuration is required.
|
||||
|
||||
<a name="defaultconfmapping"/>More examples:
|
||||
The table below indicates how ivy interpret the conf attribute according to how <a href="../ivyfile/configurations.html">defaultconfmapping</a> is set:<table class="ivy-attributes"><thead><tr><th>defaultconfmapping</th><th>conf</th><th>ivy interpretation</th></tr>
|
||||
The table below indicates how ivy interpret the conf attribute according to how [[ivyfile/configurations defaultconfmapping]] is set:<table class="ivy-attributes"><thead><tr><th>defaultconfmapping</th><th>conf</th><th>ivy interpretation</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td></td><td></td><td><code>*->*</code></td></tr>
|
||||
|
|
@ -138,7 +138,7 @@ See <a href="../ivyfile/conflicts.html">conflicts manager</a> for details.
|
|||
<tr><td>name</td><td>the module name of the dependency</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>branch</td><td>the branch of the dependency. <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to the default branch <a href="../configuration/conf.html">configured</a> for the dependency.</td></tr>
|
||||
<td>No, defaults to the default branch [[settings/conf.html setting]] for the dependency.</td></tr>
|
||||
<tr><td>rev</td><td>the revision of the dependency. See <a href="#revision">above</a> for details.</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>revConstraint</td><td>the dynamic revision constraint originally used for this dependency. See <a href="#revision-constraint">above</a> for details.</td>
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> include <b>Parent:</b> <a href="../ivyfile/configurations.html">configurations</a>
|
||||
<b>Tag:</b> include <b>Parent:</b> [[ivyfile/configurations]]
|
||||
|
||||
Include configurations specified in another file. <span class="since">since 1.3</span>
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Gives identification and basic information about the module this ivy file descri
|
|||
<tr><td>module</td><td>the name of the module described by this ivy file.</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>branch</td><td>the branch of this module. <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to the default branch <a href="../configuration/conf.html">configured</a>, or nothing if no default branch is configured</td></tr>
|
||||
<td>No, defaults to the default branch [[settings/conf setting]], or nothing if no default branch is configured</td></tr>
|
||||
<tr><td>revision</td><td>the revision of this module.</td>
|
||||
<td>Yes in repository ivy files, no in ivy files to resolve</td></tr>
|
||||
<tr><td>status</td><td>the status of this module. See <a href="../reference.html">terminology</a> section for details</td>
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ As the title suggest, here you will have some explanations on how does ivy work
|
|||
<li>[[install]]</li>
|
||||
This part describe how to install Ivy
|
||||
</ul>
|
||||
<li>[[configuration]]</li>
|
||||
<li>[[settings]]</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>[[ivyfile]]</li>
|
||||
This part is the reference of the specification of the module descriptors, the ivy 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.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@
|
|||
|
||||
This resolver is only a container of a chain of other resolvers. The sub resolvers can be any resolver, including a chain. An attribute enable to indicate if the chain must be iterated after the first found or not (at least when asking for a latest revision). If the chain is iterated, then it's the latest among the ones found that is returned. If the chain is not iterated, then it's the first found which is returned.
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of composite resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of composite resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@
|
|||
This resolver delegates its job to one resolver for ivy files and another for artifacts.
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of composite resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of composite resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ The <b>transactional</b> attribute can be used to configure the atomicity behavi
|
|||
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
@ -68,7 +68,7 @@ This resolver shares the <a href="../configuration/resolvers.html#common">common
|
|||
<tbody>
|
||||
<tr><td>m2compatible</td><td>True if this resolver should be maven2 compatible, false otherwise <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
<tr><td>local</td><td>True if this resolver should be considered local, false otherwise <span class="since">since 1.4</span>. See useOrigin attribute on the [[configuration/caches]] element for details.</td>
|
||||
<tr><td>local</td><td>True if this resolver should be considered local, false otherwise <span class="since">since 1.4</span>. See useOrigin attribute on the [[settings/caches]] element for details.</td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
<tr><td>transactional</td><td>true to force the use of transaction, false to prevent the use of transaction, auto to get transaction when possible <span class="since">since 2.0</span>. See above for details.</td>
|
||||
<td>No, defaults to auto</td></tr>
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ This resolver usually uses ibiblio to find artifacts.
|
|||
<strong>Limitation</strong>: in m2compatible mode, this resolver is not able list available organizations. It means some features like [[ant:repreport]] are not available.
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Since ivyrep is not maintained anymore, the ivyroot attribute is mandatory, and
|
|||
</div>
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Because the downloading and packaging process is relatively slow, it is importan
|
|||
</p>
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Note that the authentication features of this resolver are exactly the same as t
|
|||
Internally this resolver relies on <a href="http://www.jcraft.com/jsch/">jsch</a> as ssh client, which is a popular java ssh client, used for example in eclipse.
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ If your server supports sftp, you can consider using the <a href="../resolver/sf
|
|||
|
||||
Internally this resolver shares most of its behaviour with the <a href="../resolver/sftp.html">sftp resolver</a>, so refer to its documentation for details.
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ This resolver is one of the most generic, in fact most of the previous resolvers
|
|||
<strong>Limitation</strong>: in m2compatible mode, this resolver is not able list available organizations. It means some features like [[ant:repreport]] are not available.
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ This resolver is certainly the most capable, since it relies on <a href="http://
|
|||
<i>Note: commons vfs has not released a stable version yet, hence Ivy relies on a nightly build. Stability should thus be considered carefully before using this resolver in a production environment</i>
|
||||
|
||||
<h1>Attributes</h1>
|
||||
This resolver shares the <a href="../configuration/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
This resolver shares the <a href="../settings/resolvers.html#common">common attributes</a> of standard resolvers.
|
||||
<h1>Child elements</h1>
|
||||
<table class="ivy-children">
|
||||
<thead>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,156 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 0};</script>
|
||||
<script type="text/javascript" src="xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
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="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 use the [[ant:settings]] datatype with the path of your settings file.
|
||||
|
||||
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="settings/property.html">property</a>
|
||||
<a href="settings/properties.html">properties</a>
|
||||
<a href="settings/conf.html">settings</a>
|
||||
<a href="settings/include.html">include</a>
|
||||
<a href="settings/classpath.html">classpath</a>
|
||||
<a href="settings/typedef.html">typedef</a>
|
||||
<a href="settings/lock-strategies.html">lock-strategies</a>
|
||||
<a href="settings/caches.html">caches</a>
|
||||
<a href="settings/caches/cache.html">cache</a>
|
||||
<a href="settings/latest-strategies.html">latest-strategies</a>
|
||||
<a href="settings/version-matchers.html">version-matchers</a>
|
||||
<a href="settings/triggers.html">triggers</a>
|
||||
<a href="settings/parsers.html">parsers</a>
|
||||
<a href="settings/conflict-managers.html">conflict-managers</a>
|
||||
<a href="settings/outputters.html">outputters</a>
|
||||
<a href="settings/namespaces.html">namespaces</a>
|
||||
<a href="settings/namespace.html">namespace</a>
|
||||
<a href="settings/namespace/rule.html">rule</a>
|
||||
<a href="settings/namespace/fromtosystem.html">fromsystem</a>
|
||||
<a href="settings/namespace/src.html">src</a>
|
||||
<a href="settings/namespace/dest.html">dest</a>
|
||||
<a href="settings/namespace/fromtosystem.html">tosystem</a>
|
||||
<a href="settings/namespace/src.html">src</a>
|
||||
<a href="settings/namespace/dest.html">dest</a>
|
||||
<a href="settings/macrodef.html">macrodef</a>
|
||||
<a href="settings/macrodef/attribute.html">attribute</a>
|
||||
any resolver
|
||||
<a href="settings/resolvers.html">resolvers</a>
|
||||
any resolver
|
||||
<a href="settings/modules.html">modules</a>
|
||||
<a href="settings/module.html">module</a>
|
||||
<a href="settings/statuses.html">statuses</a>
|
||||
<a href="settings/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="settings/property.html">property</a></td><td>set an ivy variable</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="settings/properties.html">properties</a></td><td>loads a properties file as ivy variables</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="settings/conf.html">settings</a></td><td>configures ivy with some defaults</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/include.html">include</a></td><td>includes another settings file</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="settings/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="settings/typedef.html">typedef</a></td><td>defines new types in ivy</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="settings/lock-strategies.html">lock-strategies</a></td><td>defines lock strategies</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/caches.html">caches</a></td><td>defines repository cache managers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/latest-strategies.html">latest-strategies</a></td><td>defines latest strategies</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/parsers.html">parsers</a></td><td>defines module descriptor parsers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/version-matchers.html">version-matchers</a></td><td>defines new version matchers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/triggers.html">triggers</a></td><td>register triggers on ivy events</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/namespaces.html">namespaces</a></td><td>defines new namespaces</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/macrodef.html">macrodef</a></td><td>defines a new macro resolver</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td><a href="settings/resolvers.html">resolvers</a></td><td>defines dependency resolvers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/conflict-managers.html">conflict-managers</a></td><td>defines conflicts managers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/modules.html">modules</a></td><td>defines rules between modules and dependency resolvers</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/outputters.html">outputters</a></td><td>defines the list of available report outputters</td>
|
||||
<td>0..1</td></tr>
|
||||
<tr><td><a href="settings/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>
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> caches
|
||||
|
||||
Configures the Ivy cache system. <span class="since">since 2.0</span>.
|
||||
See <a href="../concept.html#cache">cache concept</a> for details on the Ivy cache concept.
|
||||
|
||||
By default, Ivy defines one repository cache instance, called 'default-cache', which uses the default cache settings defined using attributes on this tag. This default instance is defined as long as you don't define your own default cache using the 'default' attribute, and have at least one dependency resolver which doesn't specify which cache instance to use.
|
||||
|
||||
<em>defaultCacheDir</em> is the default directory used for both the resolution and repository cache(s). It usually points to a directory in your filesystem. If you want to isolate resolution cache from repository cache, we recommend setting both the resolutionCacheDir and repositoryCacheDir attributes on this tag instead of using defaultCacheDir.
|
||||
|
||||
Since repository cache implementations are pluggable, you can either define new cache instances based on the default implementation provided in Ivy using the [[settings/caches/cache]] child element, or use custom cache implementations using child elements as you have defined using [[settings/typedef]].
|
||||
|
||||
<em>ivyPattern</em> and <em>artifactPattern</em> are used to configure the default way Ivy stores ivy files and artifacts in repository cache(s). Usually you do not have to change this, unless you want to use the cache directly from another tool, which is not recommended. These patterns are relative to the repository cache base directory.
|
||||
|
||||
<em>checkUpToDate</em> 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.
|
||||
|
||||
<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>default</td><td>the name of the default cache to use on all resolvers not defining the cache instance to use</td>
|
||||
<td>No, defaults to a default cache manager instance named 'default-cache'</td></tr>
|
||||
<tr><td>defaultCacheDir</td><td>a path to a directory to use as default basedir for both resolution and repository cache(s)</td>
|
||||
<td>No, defaults to .ivy2/cache in the user's home directory</td></tr>
|
||||
<tr><td>resolutionCacheDir</td><td>the path of the directory to use for all resolution cache data</td>
|
||||
<td>No, defaults to defaultCacheDir</td></tr>
|
||||
<tr><td>repositoryCacheDir</td><td>the path of the default directory to use for repository cache data. <strong>This should not point to a directory used as a repository!</strong></td>
|
||||
<td>No, defaults to defaultCacheDir</td></tr>
|
||||
<tr><td>ivyPattern</td><td>default pattern used to indicate where ivy files should be put in the repository cache(s)</td>
|
||||
<td>No, defaults to [organisation]/[module]/ivy-[revision].xml</td></tr>
|
||||
<tr><td>artifactPattern</td><td>default pattern used to indicate where artifact files should be put in the repository cache(s)</td>
|
||||
<td>No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]</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>useOrigin</td><td>the default value to use for useOrigin for caches in which it isn't specifically defined.
|
||||
Use true to avoid the copy of local artifacts to the cache and use directly their original location.</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
<tr><td>lockStrategy</td><td>the name of the default [[settings/lock-strategies lock strategy]] to use when accessing repository cache(s)</td>
|
||||
<td>No, defaults to <em>no-lock</em></td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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><a href="caches/cache.html">cache</a></td><td>defines a new repository cache instance, based on the default repository cache implementation</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<caches>
|
||||
<cache name="mycache" basedir="path/to/my/cache/1" />
|
||||
<cache name="mycache2" basedir="path/to/my/cache/2" />
|
||||
</caches>
|
||||
</code>
|
||||
Define 2 cache instances, named mycache and mycache2, using two different directories as base directory, and using the default patterns and lock strategies. The default cache instance will still be defined as long as at least one dependency resolver does not declare which cache manager to use.
|
||||
<hr/></textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> cache
|
||||
|
||||
Defines a repository cache instance based on the default repository cache implementation.
|
||||
|
||||
The default repository cache implementation caches files on the local filesystem in subdirectories of a configured base directory.
|
||||
|
||||
<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>name</td><td>name of the cache instance</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>basedir</td><td>the path of the base directory to use to put repository cache data. <strong>This should not point to a directory used as a repository!</strong></td>
|
||||
<td>No, defaults to repositoryCacheDir defined in [[settings/caches]]</td></tr>
|
||||
<tr><td>ivyPattern</td><td>the pattern to use to store cached ivy files</td>
|
||||
<td>No, defaults to default cache ivy pattern as configured in [[settings/caches]]</td></tr>
|
||||
<tr><td>artifactPattern</td><td>the pattern to use to store cached artifacts</td>
|
||||
<td>No, defaults to default cache artifact pattern as configured in [[settings/caches]]</td></tr>
|
||||
<tr><td>useOrigin</td><td>true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise.
|
||||
To know if an artifact is local ivy asks to the resolver. Only filesystem resolver is considered local by default, but this can be disabled if you want to force the copy on one filesystem resolver and use the original location on another. Note that it is safe to use useOrigin even if you use the cache for some non local resolvers. In this case the cache will behave as usual, copying files to the cache. Note also that this only applies to artifacts, not to ivy files, which are still copied in the cache.</td>
|
||||
<td>No. defaults to the default value configured in [[settings/caches]]</td></tr>
|
||||
<tr><td>lockStrategy</td><td>the name of the [[settings/lock-strategies lock strategy]] to use for this cache</td>
|
||||
<td>No, defaults to default lock strategy as configured in [[settings/caches]]</td></tr>
|
||||
<tr><td>defaultTTL</td><td>the default [[settings/caches/ttl TTL]] to use when no specific one is defined</td>
|
||||
<td>No, defaults to ${ivy.cache.ttl.default}</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<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>[[settings/caches/ttl]]</td><td>defines a TTL rule</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Examples</h1>
|
||||
<code>
|
||||
<cache name="mycache"
|
||||
basedir="/path/to/mycache"
|
||||
ivyPattern="[module]/ivy-[revision].xml"
|
||||
artifactPattern="[module]/[artifact]-[revision].[ext]"
|
||||
lockStrategy="no-lock"
|
||||
defaultTTL="1s">
|
||||
<ttl revision="latest.integration" duration="200ms" />
|
||||
<ttl organisation="org1" duration="10m 20s" />
|
||||
<ttl organisation="org2" duration="5h" />
|
||||
<ttl organisation="org3" duration="2d 12h" />
|
||||
</cache>
|
||||
</code>
|
||||
Defines a cache called 'mycache', storing files in the '/path/to/mycache' directory using '[module]/ivy-[revision].xml' as pattern to store Ivy files and '[module]/[artifact]-[revision].[ext]' as pattern to store other artifacts.
|
||||
The lock strategy used by this cache is the 'no-lock' strategy, which does not perform any locking.
|
||||
The defaultTTL used is of 1s, meaning that by default dynamic revision result will be stored and used for one second. TTL rules then define that all 'latest.integration' revisions will be stored and used for 200ms, while other dynamic revisions from org1 org2 and org3 modules will be stored respectively for 10 minutes 20 seconds; 5 hours; and 2 days and 12 hours.</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> ttl
|
||||
|
||||
<span class="since">Since 2.0</span> Defines a TTL (Time To Live) rule for resolved revision caching.
|
||||
|
||||
When Ivy resolves a dynamic version constraint (like latest.integration or a version range), it can store the result of the resolution (like latest.integration=1.5.1) for a given time, called TTL. It means that Ivy will reuse this dynamic revision resolution result without accessing the repositories for the duration of the TTL, unless running [[ant:resolve]] in refresh mode.
|
||||
|
||||
This tag let you define a rule to define a TTL specific to a set of dynamic revision, based on the whole module revision information (organization, module name, revision, ...). The revision considered in the rule is the revision before the resolution (for instance 'latest.integration') and not the resolved revision (for instance '1.5.1').
|
||||
|
||||
The rules are evaluated in order, the first matching rule being used to define the TTL. If no rule matches, the cache defaultTTL will be used.
|
||||
|
||||
The format used to specify the TTL is of the form:
|
||||
<code>
|
||||
XXd XXh XXm XXs XXXms
|
||||
</code>
|
||||
Where 'd' stands for days, 'h' for hours, 'm' for minutes, 's' for seconds and 'ms' for milliseconds. Any part of the specification can be omitted, so '12d', '2h 5m' and '1d 5ms' are all valid.
|
||||
|
||||
Using a 0ms TTL disable resolved revision caching for the given rule.
|
||||
|
||||
<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>organisation</td><td>the organisation to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>module</td><td>the module's name to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>revision</td><td>the module's revision to match to apply the rule. Note that the version is not resolved when evaluating the rule ('latest.integration' for instance).</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td><em>any extra attribute</em></td><td>an extra attribute to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>matcher</td><td>the <a href="../../concept.html#matcher">matcher</a> to use to match the modules to which the resolver should be applied</td>
|
||||
<td>No, defaults to exact</td></tr>
|
||||
<tr><td>duration</td><td>the TTL to apply</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<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">
|
||||
<ivysettings>
|
||||
<classpath file="${ivy.settings.dir}/custom-resolver.jar"/>
|
||||
<typedef name="custom" classname="org.apache.ivy.resolver.CustomResolver"/>
|
||||
<resolvers>
|
||||
<custom name="custom"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
Adds custom-resolver.jar found in the same directory as the ivysettings.xml file itself to the classpath, then define a custom resolver and use it.
|
||||
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<classpath url="http://www.myserver.com/ivy/custom-resolver.jar"/>
|
||||
<typedef name="custom" classname="org.apache.ivy.resolver.CustomResolver"/>
|
||||
<resolvers>
|
||||
<custom name="custom"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
Same as above, but find the jar on a web server.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> conflict-managers
|
||||
|
||||
Defines a list of <a href="../concept.html#conflict">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>latest-compatible</li> this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end this conflict manager does not allow any conflict (like the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
|
||||
<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="../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>compatible-cm</li>The latest compatible conflict manager uses a latest strategy to select the latest revision among several ones. It takes 'latest' as attribute to define which latest strategy should be used. Example:
|
||||
<code><compatible-cm name="my-latest-compatible-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>
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> include
|
||||
|
||||
Includes another ivysettings file as if it were part of this one. <span class="since">since 1.3</span>
|
||||
|
||||
The included ivysettings file has to be a complete well formed ivysettings file, i.e. it does have to include the <code><ivysettings></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 ivysettings file to include</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<property name="myrepository" value="path/to/my/real/rep"/>
|
||||
<settings defaultResolver="default"/>
|
||||
<include file="path/to/ivysettings-default.xml"/>
|
||||
</ivysettings>
|
||||
</code>
|
||||
with ivysettings-default.xml:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<property name="myrepository" value="path/to/rep" overwrite="false"/>
|
||||
<resolvers>
|
||||
<ivyrep name="default" ivyroot="${myrepository}"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
The included ivysettings 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 override the value given in the main ivysettings including this one, so the value used for myrepository will be path/to/my/real/rep.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<include file="ivysettings-macro.xml"/>
|
||||
<resolvers>
|
||||
<mymacro name="includeworks" mymainrep="included/myrep" mysecondrep="included/secondrep"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
with ivysettings-macro.xml being the ivysettings example given on the [[settings/macrodef macrodef documentation page]].
|
||||
This let reusing macro resolver easy.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> latest-strategies
|
||||
|
||||
Defines a list of <a href="../concept.html#latest">latest strategies</a> usable in ivy. Each latest strategy is identified by its name, given as an attribute.
|
||||
The child tag used for the latest strategy must be equal to a name of a latest strategy type (usually added with the typedef tag).
|
||||
|
||||
The latest strategies which are always included in ivy (and do not require anything in the configuration file) are:
|
||||
<ul>
|
||||
<li>latest-time</li> 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> 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> compares the revisions as string, using lexicographic order (the one used by java string comparison).
|
||||
</ul>
|
||||
|
||||
<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 latest strategy</td><td>adds a latest strategy to the list of available strategies</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>latest-revision</h1>
|
||||
<span class="since">since 1.4</span> The latest-revision can now be configured to handle more words with special meanings than the one defined in php version_compare function.
|
||||
|
||||
Here is an example of how you can do so:
|
||||
<code type="xml">
|
||||
<latest-strategies>
|
||||
<latest-revision name="mylatest-revision">
|
||||
<specialMeaning name="PRE" value="-2"/>
|
||||
<specialMeaning name="QA" value="4"/>
|
||||
<specialMeaning name="PROD" value="5"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</code>
|
||||
Knowing that the default special meaning words are the following:
|
||||
<code type="xml">
|
||||
<specialMeaning name="dev" value="-1"/>
|
||||
<specialMeaning name="rc" value="1"/>
|
||||
<specialMeaning name="final" value="2"/>
|
||||
</code>
|
||||
You can even get rid or redefine the default special meanings by setting usedefaultspecialmeanings="false" on the latest-revision tag.
|
||||
Example:
|
||||
<code type="xml">
|
||||
<latest-strategies>
|
||||
<latest-revision name="mylatest-revision" usedefaultspecialmeanings="false">
|
||||
<specialMeaning name="pre" value="-2"/>
|
||||
<specialMeaning name="m" value="1"/>
|
||||
<specialMeaning name="rc" value="2"/>
|
||||
<specialMeaning name="prod" value="3"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</code>
|
||||
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> lock-strategies <span class="since">since 2.0</span>
|
||||
|
||||
Defines a list of lock strategies usable in Ivy.
|
||||
|
||||
A lock strategy is used by a cache manager to decide when and how locking should be performed (see [[settings/cache]] to see how to configure the lock strategy to use).
|
||||
|
||||
Two lock strategies are registered by default:
|
||||
<ul>
|
||||
<li><b>no-lock</b></li> This lock strategy actually performs no locking at all, and thus should not be used in environment where the cache is shared by multiple processes.
|
||||
|
||||
This strategy is implemented by ([[svn:src/java/org/apache/ivy/plugins/lock/NoLockStrategy.java NoLockStrategy]])
|
||||
|
||||
|
||||
<li><b>artifact-lock</b></li> This strategy acquire a lock whenever a module descriptor or an artifact is downloaded to the cache, which makes a good solution when you want to share your repository cache.
|
||||
|
||||
Note that this strategy is based on file locking, performed by default using the java.io.File.createNewFile() atomicity (which is documented as atomic in the javadoc, but not recommended to perform locks). A java.nio.FileLock based implementation is also provided, but according to our tests the createNewFile based one performs better and more reliably. We heavily recommend making your own testing in your target environment before relying on this lock strategy for heavily concurrent operations.
|
||||
|
||||
This strategy is implemented by ([[svn:src/java/org/apache/ivy/plugins/lock/ArtifactLockStrategy.java ArtifactLockStrategy]])
|
||||
</ul>
|
||||
|
||||
The child tag used for the lock strategy must be equal to a name of a lock strategy type (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 lock strategy</td><td>adds a lock strategy to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table></textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,152 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> macrodef
|
||||
|
||||
Defines a new dependency resolver type based upon an other one. This definition is very similar to the macrodef feature of ant for defining macro tasks. <span class="since">since 1.3</span>
|
||||
|
||||
This task eases the lot the process of creating new dependency resolver, because it avoid writing java code.
|
||||
|
||||
It is generally used in combination with the [[settings/include]] feature to help reusing macro at several places.
|
||||
|
||||
A macro is defined by writing the resolver it is equivalent to as if it were written in the resolver place, except that you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name and sometimes a default value, and are used using the following syntax:
|
||||
<code>@{attributename}</code>
|
||||
<h2>Resolvers names</h2>
|
||||
Since you can use the same macro several times, and that your macro may define several resolvers (in a chain for instance), resolvers names need to be chosen carefully to avoid name conflicts (a resolver must have a unique name).
|
||||
|
||||
Therefore here is how Ivy deals with the names of the resolvers defined in a macro:
|
||||
<ul>
|
||||
<li>if there is no name attribute on a resolver in the macrodef, then Ivy will use the name given when using the macro. This is what usually should be done for the main resolver defined in the macro</li>
|
||||
<li>if there is a name attribute on a resolver in the macrodef, but this name doesn't contain a @{name} inside, then Ivy will use the provided name prefixed with the name of the macro separated by a dash</li>
|
||||
<li>if there is a name attribute on a resolver in the macrodef, and this name contains @{name} somewhere, then Ivy will use this name, and replace @{name} with the name provided when using the macro.
|
||||
</ul>
|
||||
|
||||
Example:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<macrodef name="mymacro">
|
||||
<chain>
|
||||
<ibiblio name="ex1" />
|
||||
<ibiblio name="ex2.@{name}" m2compatible="true" />
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" />
|
||||
<mymacro name="other" />
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
This is equivalent to:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<resolvers>
|
||||
<chain name="default">
|
||||
<ibiblio name="default-ex1" />
|
||||
<ibiblio name="ex2.default" m2compatible="true" />
|
||||
</chain>
|
||||
<chain name="other">
|
||||
<ibiblio name="other-ex1" />
|
||||
<ibiblio name="ex2.other" m2compatible="true" />
|
||||
</chain>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
<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>name</td><td>name of the resover type created</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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>[[settings/macrodef/attribute]]</td><td>defines an attribute for the macro resolver</td>
|
||||
<td>0..n</td></tr>
|
||||
<tr><td>any resolver</td><td>defines the base resolver upon which this macro is defined</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
Defining a simple macro:
|
||||
<code type="xml">
|
||||
<macrodef name="mymacro">
|
||||
<attribute name="mymainrep"/>
|
||||
<filesystem name="fs1">
|
||||
<ivy pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
<artifact pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
</macrodef>
|
||||
</code>
|
||||
Using it:
|
||||
<code type="xml">
|
||||
<resolvers>
|
||||
<mymacro name="default" mymainrep="path/to/myrep"/>
|
||||
</resolvers>
|
||||
</code>
|
||||
<hr/>
|
||||
A complete example:
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
<macrodef name="mymacro">
|
||||
<attribute name="mymainrep"/>
|
||||
<attribute name="mysecondrep"/>
|
||||
<attribute name="myseconddirlayout" default="[organisation]/[module]/[type]s"/>
|
||||
<chain>
|
||||
<filesystem name="fs1">
|
||||
<ivy pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
<artifact pattern="@{mymainrep}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
<filesystem name="fs2" latest="latest-time">
|
||||
<ivy pattern="@{mysecondrep}/@{myseconddirlayout}/ivy-[revision].xml"/>
|
||||
<artifact pattern="@{mysecondrep}/@{myseconddirlayout}/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" mymainrep="path/to/myrep" mysecondrep="path/to/secondrep"/>
|
||||
<mymacro name="other"
|
||||
mymainrep="path/to/myrep"
|
||||
mysecondrep="path/to/secondrep"
|
||||
myseconddirlayout="[module]/[type]s"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</code>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> attribute
|
||||
|
||||
Defines a macrodef attribute. See macrodef for details.
|
||||
<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>name</td><td>the name of the attribute</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>default</td><td>the default value of the attribute if none is specified</td>
|
||||
<td>No, by default attribute are required</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> module
|
||||
|
||||
Define a module set rule. The tag defines a module set, by giving an expression and the matcher to use for organisation, name, revision and any extra attribute identifying your modules. The rule matching is performed in order, and is using a pattern matcher. Hence you can use * to specify all, or simply avoid specifying the attribute.
|
||||
|
||||
The revision and extra attributes are only used for rules defining the resolver to use. For other settings, use only organisation and module name.
|
||||
|
||||
It also gives the specific setting to use for this module set.
|
||||
|
||||
For each module set, you can configure:
|
||||
<ul>
|
||||
<li>the [[settings/resolvers resolver]] to use</li>
|
||||
<li>the [[settings/conflict-managers conflict manager]] to use</li>
|
||||
<li>the default <a href="../terminology.html#branch">branch</a> to use</li>
|
||||
<li>the [[ant:resolve resolve mode]] to use</li>
|
||||
</ul>
|
||||
|
||||
<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>organisation</td><td>the organisation to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>name</td><td>the module's name to match to apply the rule.</td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>revision</td><td>the module's revision to match to apply the rule. Note that the version may not be resolved yet (be latest.integration for instance), so be very careful when using this attribute. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td><em>any extra attribute</em></td><td>an extra attribute to match to apply the rule. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to *</td></tr>
|
||||
<tr><td>matcher</td><td>the <a href="../concept.html#matcher">matcher</a> to use to match the modules to which the resolver should be applied <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to exactOrRegexp</td></tr>
|
||||
<tr><td>resolver</td><td>the name of the resolver to apply. The resolver must have been defined in the resolvers section of the configuration file.</td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>conflict-manager</td><td>the name of the conflict manager to apply. <span class="since">since 1.4</span></td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>branch</td><td>the default branch to apply. <span class="since">since 1.4</span></td>
|
||||
<td>No</td></tr>
|
||||
<tr><td>resolveMode</td><td>the resolve mode to use. <span class="since">since 2.0</span></td>
|
||||
<td>No</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="*" resolver="myprojectsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myprojectresolver for all modules from Apache.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="commons-*" matcher="glob" resolver="myapachecommonsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myapachecommonsresolver for all modules beginning by commons- from apache.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="commons-[a-z]+" myextra="val.*" matcher="regexp" resolver="myapachecommonsresolver"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses myapachecommonsresolver for all modules from 'apache' beginning by 'commons-' followed by any number of alphabetic lowercase characters, and with the extra attribute 'myextra' having a value starting with 'val'.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" conflict-manager="latest-time"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses latest-time conflict manager for all modules from apache which name begins with ivy.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" branch="fix-103"/>
|
||||
</modules>
|
||||
</code>
|
||||
Uses 'fix-103' as default branch for all modules from apache which name begins with ivy.
|
||||
|
||||
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> modules
|
||||
|
||||
Defines per module or module set settings.
|
||||
|
||||
The rules are given by defining a module set, using pattern for module organisation and name, and giving some settings for the set, like the name of the corresponding resolver to use.
|
||||
|
||||
If no rule match a given module, the default setting will be used.
|
||||
|
||||
Even if not required, because the use of a default big resolver (chain, for instance) able to resolve all dependencies can answer all the needs, the configuration of smaller resolvers used for different cases can improve performances a lot. For instance, if you have a local repository for your modules and a distant repository for third party libraries, it is a good idea to have two separate resolvers, and configure ivy to use one for all your modules and another for the rest (the default one).
|
||||
|
||||
<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>[[settings/module]]</td><td>defines a module set rule</td>
|
||||
<td>1..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> namespace
|
||||
|
||||
Defines a new namespace. A namespace is identified by a name, which is used to reference the namespace in the resolvers using the namespace.
|
||||
|
||||
Namespaces overview is given in the [[settings/namespaces]] documentation.
|
||||
|
||||
A namespace mainly consists of a list of rules, each rule defining a translation between system namespace and the defined namespace, and vice versa.
|
||||
|
||||
There are two main possibilities for using these rules. By default, a namespace iterate through the rules, and when it finds one that translate the given name, it returns the translated name. But the namespace can be configured to do use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.
|
||||
<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>name</td><td>the namespace name</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>chainrules</td><td>true to indicate that namespaces rules should be chained, false otherwise</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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>[[settings/namespace/rule]]</td><td>defines a new namespace rule</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Example</h1>
|
||||
<code type="xml">
|
||||
<namespace name="test">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg"/>
|
||||
<dest org="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="A"/>
|
||||
<dest org="systemorg"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
<code type="xml">
|
||||
<namespace name="test">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg2" module="system\-(.+)"/>
|
||||
<dest org="B" module="$m1"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="B" module=".+"/>
|
||||
<dest org="systemorg2" module="system-$m0"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
<code type="xml">
|
||||
<namespace name="test" chainrules="true">
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src org="systemorg"/>
|
||||
<dest org="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src org="A"/>
|
||||
<dest org="systemorg"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src module="systemmod"/>
|
||||
<dest module="A"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src module="A"/>
|
||||
<dest module="systemmod"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
<rule>
|
||||
<fromsystem>
|
||||
<src module="systemmod2"/>
|
||||
<dest module="B"/>
|
||||
</fromsystem>
|
||||
<tosystem>
|
||||
<src module="B"/>
|
||||
<dest module="systemmod2"/>
|
||||
</tosystem>
|
||||
</rule>
|
||||
</namespace>
|
||||
</code>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> dest
|
||||
|
||||
Defines the translation part of a translation rule. If a name has matched a corresponding src, it will be translated using this dest part.
|
||||
|
||||
The new names can contain references to groups of the matched name, using a slightly modified regexp syntax. Indeed, referenced groups can be part of either the organisation, module or revision part of the original name. So, to reference the groups, you just have to add a letter identifying the part in which the group should be selected: o for organisation, m for module, and r for revision.
|
||||
|
||||
For instance, $o0 matches the whole matched organisation, and $m0 the whole matched module name. $o1 matches the first group of the matched organisation.
|
||||
|
||||
For details about regexp and groups, see the <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html">Pattern class documentation</a> in the jdk.
|
||||
<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>org</td><td>the new organisation name</td>
|
||||
<td>No, defaults to $o0</td></tr>
|
||||
<tr><td>module</td><td>the new module name</td>
|
||||
<td>No, defaults to $m0</td></tr>
|
||||
<tr><td>rev</td><td>the new revision</td>
|
||||
<td>No, defaults to $r0</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<fromsystem>
|
||||
<src org="systemorg2" module="system\-(.+)"/>
|
||||
<dest org="B" module="$m1"/>
|
||||
</fromsystem>
|
||||
</code>
|
||||
Matches modules from systemorg2 which have a name beginning with system followed by a minus and anything else, and translate it to organisation B and module the part following <code>system-</code> of the original name.
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> fromsystem / tosystem
|
||||
|
||||
Defines a one way translation rule, i.e. a translation from system namespace to the defined namespace or vice versa.
|
||||
<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>[[settings/namespace/src]]</td><td>defines a source name which can be accepted</td>
|
||||
<td>1..n</td></tr>
|
||||
<tr><td>[[settings/namespace/dest]]</td><td>defines the translation to apply when a name is accepted by an src pattern</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> rule
|
||||
|
||||
Defines a new namespace rule. A rule defines a translation between system namespace and the defined namespace, and vice versa.
|
||||
|
||||
See [[settings/namespace]] doc for details.
|
||||
|
||||
<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>[[settings/namespace/fromtosystem fromsystem]]</a></td><td>defines the translation to apply from system namespace to the defined namespace</td>
|
||||
<td>1</td></tr>
|
||||
<tr><td>[[settings/namespace/fromtosystem tosystem]]</td><td>defines the translation to apply from the defined namespace to system namespace</td>
|
||||
<td>1</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 2};</script>
|
||||
<script type="text/javascript" src="../../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> src
|
||||
|
||||
Defines the acceptation part of a translation rule. If a name matches this src, it will be translated using the dest part.
|
||||
<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>org</td><td>the organisation to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
<tr><td>module</td><td>the module name to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
<tr><td>rev</td><td>the revision to match as a regexp</td>
|
||||
<td>No, defaults to .*</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> namespaces
|
||||
|
||||
Namespaces are an advanced feature of Ivy which let you use resolvers in which module names and organisations are not consistent between each other.
|
||||
|
||||
For instance, if you want to use maven2 repository and ivyrep collectively, you will face some naming issues. For example all apache commons projects are declared to be part of the organisation apache in ivyrep whereas in maven2 ibiblio repository, they are declared to be part of the organisation of the same name of the module.
|
||||
|
||||
So if you try to use both maven2 and ivyrep repositories, you will face some issues like:
|
||||
<quote>
|
||||
How do I declare a dependency on commons-lang ?
|
||||
I have an error while trying to resolve module xxx. It says that it depends on [commons-httpclient commons-httpclient] ant that it isn't available.
|
||||
...
|
||||
</quote>
|
||||
|
||||
Ivy has an answer to give to this kind of troubles, and this answer is called namespaces. In short, you can affect a namespace to each dependency resolver in Ivy, and each namespace defines rules to convert names from the system namespace to the defined namespace itself, and vice versa.
|
||||
|
||||
This very powerful feature is thoroughly used in the <a href="../tutorial/build-repository/advanced1.html">build your own repository tutorial</a>, and this is a good place to have examples of what can be done with namespaces.
|
||||
|
||||
<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>[[settings/namespace]]</td><td>defines a new namespace</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> outputters
|
||||
|
||||
Defines a list of report outputters usable in ivy.
|
||||
|
||||
A report outputter is used at the end of the resolve process to generate a report of how the resolve has been performed.
|
||||
|
||||
Two report outputters are registered by default:
|
||||
<ul>
|
||||
<li>a log report outputter ([[svn:src/java/org/apache/ivy/plugins/report/LogReportOutputter.java LogReportOutputter]])</li>which produces the output on the console at the end of the resolve, which looks like this:
|
||||
<code>
|
||||
---------------------------------------------------------------------
|
||||
| | modules || artifacts |
|
||||
| conf | number| search|dwnlded|evicted|| number|dwnlded|
|
||||
---------------------------------------------------------------------
|
||||
| default | 1 | 1 | 0 | 0 || 1 | 1 |
|
||||
---------------------------------------------------------------------
|
||||
</code>
|
||||
<li>an xml report outputter ([[svn:src/java/org/apache/ivy/plugins/report/XmlReportOutputter.java XmlReportOutputter]])</li>which produces an xml report in the cache, which is mandatory for correct Ivy behaviour, since it's that report which is used when you do a post resolve step in a separate buid from the resolve itself. It's also this xml report which is processed to generate all the different reports available in the [[ant:report]] task.
|
||||
</ul>
|
||||
|
||||
The child tag used for the parser must be equal to a name of a report outputter type (added with the typedef tag).
|
||||
|
||||
To see how to define your own report outputter see <a href="../extend.html">Extending Ivy documentation</a>
|
||||
|
||||
<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 report outputter</td><td>adds a report outputter to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> parsers
|
||||
|
||||
Defines a list of module descriptor parsers usable in ivy. Each parser defines which resources (which descriptor file) it accepts.
|
||||
The child tag used for the parser must be equal to a name of a parser type (added with the typedef tag).
|
||||
|
||||
Note that when looking for a parser, ivy queries the parsers list in the reverse order. So the last parser in the list will be queried first. Consequently, if the last parser accepts all resources, the other parsers will never have a chance to parse the resource.
|
||||
|
||||
Two parsers are available by default and thus do not need to be declared in this section:
|
||||
<ul>
|
||||
<li>ivy file parser</li> this is the parser used for ivy xml files. This parser is used for resources that aren't accepted by any other parser.
|
||||
<li>pom parser</li>this parser is able to parse maven2 pom files
|
||||
</ul>
|
||||
<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 module descriptor parser</td><td>adds a module descriptor parser to the list of available parsers</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> properties<br/>
|
||||
<br/>
|
||||
Loads a properties file into ivy variables. See variables chapter above for details about ivy variables.
|
||||
|
||||
<span class="since">Since 2.0</span>: it is possible to access environment variables. This can be done by specifying the environment attribute. This attribute specifies the prefix which can be used to access these environment variables. For instance, if you specify environment="env", you can access the PATH environment variable with the env.PATH property name.
|
||||
|
||||
<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 a properties file to load</td>
|
||||
<td rowspan="2">One of these</td></tr>
|
||||
<tr><td>environment</td><td>the prefix to use when retrieving environment variables <span class="since">(since 2.0)</span></td>
|
||||
<tr><td>override</td><td>indicates if the variable found in the properties file should override their previous value, if any <span class="since">(since 1.3)</span></td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> property
|
||||
|
||||
Defines an ivy variable. <span class="since">since 1.3</span>
|
||||
|
||||
The optional override attribute enables to avoid overriding the previous value of the varable, which makes the definition behave like ant properties, which is particularly useful to define default values (values which are used only if they haven't been defined yet).
|
||||
<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>name</td><td>the name of the variable to define</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>value</td><td>the new value the variable must take</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>override</td><td>true if the previous value (if any) of the variable should overriden, false otherwise</td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<property name="myvar" value="myvalue"/>
|
||||
</code>
|
||||
Sets the variable myvar to the value myvalue.
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<property name="myvar" value="myvalue" override="false"/>
|
||||
</code>
|
||||
Sets the variable myvar to the value myvalue only if myvar has not been set yet.
|
||||
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,197 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> resolvers
|
||||
|
||||
Defines a list of dependency resolvers usable in ivy. Each dependency resolver is identified by its name, given as an attribute.
|
||||
|
||||
The child tag used for the dependency resolver must be equal to a name of a dependency resolver type (either built-in or added with the typedef tag).
|
||||
|
||||
<span class="since">since 1.3</span> Once defined, resolvers can be referenced by their name, using the following syntax:
|
||||
<code type="xml">
|
||||
<resolver ref="alreadydefinedresolver"/>
|
||||
</code>
|
||||
Note that this works only if the resolver has been already defined, and not if it is defined later in the ivysettings file.
|
||||
<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 resolver</td><td>adds a resolver to the list of available resolvers</td>
|
||||
<td>1..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Built-in Resolvers</h1>
|
||||
Ivy comes with a set of built-in dependency resolvers able to answer to the most common needs.
|
||||
|
||||
If you don't find the one you want here, you can also check if some one has not contributed it in the [[links links page]], or even <a href="../extend.html">write your own</a>.
|
||||
|
||||
There are basically two types of resolver in Ivy: composite and standard resolvers. A composite resolver is a resolver which delegates the work to other resolvers. The other resolvers are standard resolvers.
|
||||
|
||||
Here is the list of built-in resolvers:
|
||||
|
||||
<table class="ivy-attributes">
|
||||
<thead>
|
||||
<tr><th>Name</th><th>Type</th><th>Description</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><a href="../resolver/ivyrep.html">IvyRep</a></td><td>Standard</td><td>Finds ivy files on ivyrep and artifacts on ibiblio.</td></tr>
|
||||
<tr><td><a href="../resolver/ibiblio.html">IBiblio</a></td><td>Standard</td><td>Finds artifacts on ibiblio.</td></tr>
|
||||
<tr><td><a href="../resolver/packager.html">Packager</a></td><td>Standard</td><td>Finds ivy files and packaging instructions via URLs, then creates artifacts by following the instructions.</td></tr>
|
||||
<tr><td><a href="../resolver/filesystem.html">FileSystem</a></td><td>Standard</td><td>This very performant resolver finds ivy files and artifacts in your file system.</td></tr>
|
||||
<tr><td><a href="../resolver/url.html">Url</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with urls.</td></tr>
|
||||
<tr><td><a href="../resolver/vfs.html">Vfs</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with <a href="http://jakarta.apache.org/commons/vfs/">apache commons vfs</a>.</td></tr>
|
||||
<tr><td><a href="../resolver/ssh.html">ssh</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with ssh.</td></tr>
|
||||
<tr><td><a href="../resolver/sftp.html">sftp</a></td><td>Standard</td><td>Finds ivy files and artifacts in any repository accessible with sftp.</td></tr>
|
||||
<tr><td><a href="../resolver/chain.html">Chain</a></td><td>Composite</td><td>Delegates the finding to a chain of sub resolvers.</td></tr>
|
||||
<tr><td><a href="../resolver/dual.html">Dual</a></td><td>Composite</td><td>Delegates the finding of ivy files to one resolver and of artifacts to another.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1><a name="common">Common features and attributes</a></h1>
|
||||
All resolvers of the same type share some common features and attributes detailed here.
|
||||
<h2>Features</h2>
|
||||
<h3>validation</h3>
|
||||
All standard resolvers support several options for validation.
|
||||
|
||||
The validate attribute is used to configure if Ivy files should be checked against the Ivy file xml schema.
|
||||
|
||||
The checkconsistency attribute allow to enable or disable consistency checking between what is expected by Ivy when it finds a module descriptor, and what the module descriptor actually contains.
|
||||
|
||||
The descriptor attribute let one define if module descriptors are mandatory or optional.
|
||||
|
||||
The checksums attribute is used to define the list of checksums files to use to check the content of downloaded files has not been corrupted (eg during transfer).
|
||||
<h3>force</h3>
|
||||
Any standard resolver can be used in force mode, which is used mainly to handle local development builds. In force mode, the resolver attempts to find a dependency whatever the requested revision is (internally it replace the requested revision by 'latest.integration'), and if it finds one, it forces this revision to be returned, even when used in a chain with returnFirst=false.
|
||||
|
||||
By using such a resolver at the beginning of a chain, you can be sure that Ivy will pick up whatever module is available in this resolver (usually a private local build) instead of the real requested revision. This allows to handle use case like a developer working on modules A and C, where A -> B -> C, and pick up the local build for C without having to publish a local version of B.
|
||||
<span class="since">since 2.0</span>
|
||||
|
||||
<h2>Attributes</h2>
|
||||
<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><th>Composite</th><th>Standard</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>name</td><td>the name which identify the resolver</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>validate</td><td>indicates if resolved ivy files should be validated against ivy xsd</td>
|
||||
<td>No, defaults to call setting</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>force</td><td>Indicates if this resolver should be used in force mode (see above). <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to false</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checkmodified</td><td>Indicates if this resolver should check lastmodified date to know if an ivy file is up to date.</td>
|
||||
<td>No, defaults to ${ivy.resolver.default.check.modified}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>changingPattern</td><td>Indicates for which revision pattern this resolver should check lastmodified date to know if an artifact file is up to date. <span class="since">since 1.4</span>. See <a href="../concept.html#change">cache and change management</a> for details.</td>
|
||||
<td>No, defaults to none</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>changingMatcher</td><td>The name of the <a href="../concept.html#matcher">pattern matcher</a> to use to match a revision against the configured changingPattern. <span class="since">since 1.4</span>. See <a href="../concept.html#change">cache and change management</a> for details.</td>
|
||||
<td>No, defaults to exactOrRegexp</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>alwaysCheckExactRevision</td><td>Indicates if this resolver should check the given revision even if it's a special one (like latest.integration). <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to ${ivy.default.always.check.exact.revision}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>namespace</td><td>The name of the namespace to which this resolver belong <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to 'system'</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checkconsistency</td><td>true to check consistency of module descriptors found by this resolver, false to avoid consistency check <span class="since">since 1.3</span></td>
|
||||
<td>No, defaults to true</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>descriptor</td><td>'optional' if a module descriptor (usually an ivy file) is optional for this resolver, 'required' to refuse modules without module descriptor <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to 'optional'</td>
|
||||
<td>No (except dual)</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>allownomd</td><td><em>DEPRECATED. Use descriptor="required | optional" instead.</em>
|
||||
true if the absence of module descriptor (usually an ivy file) is authorised for this resolver, false to refuse modules without module descriptor <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to true</td>
|
||||
<td>No (except dual)</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>checksums</td><td>a comma separated list of <a href="../concept.html#checksum">checksum algorithms</a> to use both for publication and checking <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to ${ivy.checksums}</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>latest</td><td>The name of the latest strategy to use.</td>
|
||||
<td>No, defaults to 'default'</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr><td>cache</td><td>The name of the cache manager to use.</td>
|
||||
<td>No, defaults to the value of the default attribute of caches</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<resolvers>
|
||||
<filesystem name="1" cache="cache-1">
|
||||
<ivy pattern="${ivy.settings.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
|
||||
<artifact pattern="${ivy.settings.dir}/1/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
<chain name="chain1">
|
||||
<resolver ref="1"/>
|
||||
<ivyrep name="ivyrep"/>
|
||||
</chain>
|
||||
<chain name="chain2" returnFirst="true" dual="true">
|
||||
<resolver ref="1"/>
|
||||
<ibiblio name="ibiblio"/>
|
||||
</chain>
|
||||
</resolvers>
|
||||
</code>
|
||||
Defines a filesystem resolver, named '1', which is then used in two chains, the first which seconds the filesystem resolver with an ivyrep resolver, and second which seconds the filesystem resolver with an ibiblio resolver, and which returns the first module found, and uses the whole chain to download artifacts (see corresponding resolvers documentation for details about them). Resolver 1 will use a cache named 'cache-1' which should have been defined under the caches element.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> settings
|
||||
|
||||
Configures some important ivy info: default resolver, latest strategy, conflict manager...
|
||||
|
||||
Default resolver is used whenever nothing else is configured in the modules section of the settings file. It should give the name of a dependency resolver defined in the [[settings/resolvers]] section of the settings file.
|
||||
|
||||
Default latest strategy and conflict manager can also be configured here.
|
||||
|
||||
<em>validate</em> indicates if ivy files should generally be validated against the xsd or not. This setting is only a default value, and can be overridden:
|
||||
1) in ant tasks
|
||||
2) in resolvers
|
||||
So if there is a setting in the resolver, it always wins against all other settings.
|
||||
|
||||
<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>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 [[settings/module module specific branch setting]]. <span class="since">since 1.4</span></td>
|
||||
<td>No, defaults to no default branch</td></tr>
|
||||
<tr><td>defaultResolveMode</td><td>the default [[ant:resolve resolve mode]] to use for all modules, except if they have a [[settings/module module specific resolve mode setting]]. <span class="since">since 2.0</span></td>
|
||||
<td>No, defaults to 'default'</td></tr>
|
||||
<tr><td><a name="circularDependencyStrategy"></a>circularDependencyStrategy</td><td>the name of the <a href="../concept.html#circular">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>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>
|
||||
<tr><td><s>defaultCache</s></td><td>a path to a directory to use as default basedir for both resolution and repository cache(s).
|
||||
<i>Deprecated, we recommend using defaultCacheDir on the [[settings/caches]] tag instead</i></td>
|
||||
<td>No, defaults to .ivy2/cache in user home</td></tr>
|
||||
<tr><td><s>checkUpToDate</s></td><td>Indicates if date should be checked before retrieving artifacts from cache.
|
||||
<i>Deprecated, we recommend using checkUpToDate on the [[settings/caches]] tag instead</i></td>
|
||||
<td>No, defaults to true</td></tr>
|
||||
<tr><td><s>cacheIvyPattern</s></td><td>a pattern to indicate where ivy files should be put in cache.
|
||||
<i>Deprecated, we recommend using ivyPattern on the [[settings/caches]] tag instead</i></td>
|
||||
<td>No, defaults to [organisation]/[module]/ivy-[revision].xml</td></tr>
|
||||
<tr><td><s>cacheArtifactPattern</s></td><td>a pattern to indicate where artifact files should be put in cache.
|
||||
<i>Deprecated, we recommend using artifactPattern on the [[settings/caches]] tag instead</i></td>
|
||||
<td>No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> status
|
||||
|
||||
Define one available module status.
|
||||
|
||||
See [[settings/statuses]] page for details about how statuses are defined.
|
||||
|
||||
<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>name</td><td>name of status defined</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>integration</td><td>true if this is an integration status, false otherwise</td>
|
||||
<td>No, defaults to false</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> statuses
|
||||
|
||||
Defines the list of available statuses. <span class="since">since 1.4</span>
|
||||
|
||||
By default, ivy has 3 statuses: release, milestone and integration. By adding a statuses section to your ivysettings file, you define the statuses you want to use. Note that in this case if you still want to have ivy default statuses you will have to declare them.
|
||||
|
||||
The integration property on each status is only used for recursive delivery, an integration dependency being delivered if the caller is not in integration state itself.
|
||||
|
||||
The default status is the one used when none is defined in a module descriptor. If not specified, it defaults to the last defined status.
|
||||
|
||||
The statuses order is important, the first is considered the more mature, the last the less mature. This is used to know if a status is compatible with a latest.<status> version matcher.
|
||||
|
||||
<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>default</td><td>the name of the status to use when none is declared in an ivy file</td>
|
||||
<td>No, defaults to the last status declared</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<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>[[settings/status]]</td><td>defines a new status</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h1>Examples</h1>
|
||||
<code type="xml">
|
||||
<statuses default="bronze">
|
||||
<status name="gold" integration="false"/>
|
||||
<status name="silver" integration="false"/>
|
||||
<status name="bronze" integration="true"/>
|
||||
</statuses>
|
||||
</code>
|
||||
Defines 3 statuses, gold, silver and bronze. The default status used when none is declared in an ivy file will be bronze.
|
||||
It is also considered as an integration status, and thus doesn't trigger any recrusive delivery.
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,311 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<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="../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 at the beginning of the resolve process, before a module dependencies and transitive dependencies are 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>req-revision</li>the requested revision for the dependency <span class="since">since 2.0</span> (provided for consistency with post-resolve-dependency)
|
||||
<li>req-revision-default</li>the default requested revision constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-dynamic</li>the requested revision dynamic constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>revision</li>the requested revision 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 this case resolved means resolving the actual revision if the requested revision is a version constraint and not a static version, and downloading all necessary metadata information.</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>req-revision</li>the requested revision for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-default</li>the default requested revision constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>req-revision-dynamic</li>the requested revision dynamic constraint for the dependency <span class="since">since 2.0</span>
|
||||
<li>revision</li>the revision of the dependency resolved, or the requested revision if the resolution was not successful
|
||||
<li>resolved</li>true if the resolution was successful, false otherwise
|
||||
<li>duration</li>the time elapsed to resolve the dependency (in ms) <span class="since">since 2.0</span>
|
||||
<li>resolver</li>the name of the resolver used to resolve the dependency
|
||||
<li>any extra attribute</li>all extra attributes found on the info tag of the resolved dependency are available <span class="since">since 2.0</span>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired after each dependency is resolved</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
|
||||
<li>resolve-id</li>the identifier of the resolution process <span class="since">since 2.0</span>
|
||||
<li>nb-dependencies</li>total number of dependencies, including transitive and evicted ones <span class="since">since 2.0</span>
|
||||
<li>nb-artifacts</li>total number of artifacts resolved, excluding metadata artifacts <span class="since">since 2.0</span>
|
||||
<li>resolve-duration</li>the time (in ms) elapsed to resolve dependencies, before dowloading artifacts <span class="since">since 2.0</span>
|
||||
<li>download-duration</li>the time (in ms) elapsed to download all artifacts, excluding metadata artifacts downloaded during the first phase of the resolution process <span class="since">since 2.0</span>
|
||||
<li>download-size</li>the total size (in bytes) of all downloaded artifacts, excluding metadata artifacts. Only artifacts actually downloaded (not in cache or used from their original location) are considered <span class="since">since 2.0</span>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the end of the resolve process, when all module dependencies have 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>metadata</li>true if the artifact to be downloaded is a metadata artifact, false for published artifacts <span class="since">since 2.0</span>
|
||||
<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>metadata</li>true if the downloaded artifact is a metadata artifact, false for published artifacts <span class="since">since 2.0</span>
|
||||
<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>duration</li>the time elapsed to download the artifact (in ms) <span class="since">since 2.0</span>
|
||||
<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>
|
||||
<tr><td>pre-retrieve <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the module for which the dependencies will be retrieved
|
||||
<li>module</li>the name of the module for which the dependencies will be retrieved
|
||||
<li>revision</li>the revision of the module for which the dependencies will be retrieved
|
||||
<li>conf</li>comma separated list of configurations which will be retrieved
|
||||
<li>symlink</li>true if Ivy will use symbolic links instead of copies on supported platforms, false otherwise
|
||||
<li>sync</li>true if the retrieve process will be performed in sync mode, false otherwise
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the beginning of the retrieve process.</td>
|
||||
</tr>
|
||||
<tr><td>post-retrieve <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the module for which the dependencies have been retrieved
|
||||
<li>module</li>the name of the module for which the dependencies will be retrieved
|
||||
<li>revision</li>the revision of the module for which the dependencies have been retrieved
|
||||
<li>conf</li>comma separated list of configurations which have been retrieved
|
||||
<li>symlink</li>true if Ivy used symbolic links instead of copies on supported platforms, false otherwise
|
||||
<li>sync</li>true if the retrieve process has been performed in sync mode, false otherwise
|
||||
<li>duration</li>the time elapsed in ms during the retrieve process
|
||||
<li>size</li>the total size of artifacts which have actually been copied (or symlinked)
|
||||
<li>nbCopied</li>the number of artifacts copied or symlinked
|
||||
<li>nbUptodate</li>the number of artifacts which were already present and up to date at the destination location
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired at the end of the retrieve process.</td>
|
||||
</tr>
|
||||
<tr><td>pre-publish-artifact <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the artifact which is about to be published
|
||||
<li>module</li>the name of the module of the artifact which is about to be published
|
||||
<li>revision</li>the revision of the the artifact which is about to be published
|
||||
<li>artifact</li>the name of the the artifact which is about to be published
|
||||
<li>type</li>the type of the the artifact which is about to be published
|
||||
<li>ext</li>the extension of the the artifact which is about to be published
|
||||
<li>resolver</li>the name of the resolver into which the artifact is about to be published
|
||||
<li>file</li>the absolute path of the source file for the artifact
|
||||
<li>overwrite</li>"true" if the new data will overwrite existing artifacts, "false" otherwise
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired before an artifact is published into a repository</td>
|
||||
</tr>
|
||||
<tr><td>post-publish-artifact <br><span class="since">since 2.0</span></td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>organisation</li>the organisation of the artifact that was published
|
||||
<li>module</li>the name of the module of the artifact that was published
|
||||
<li>revision</li>the revision of the the artifact that was published
|
||||
<li>artifact</li>the name of the the artifact that was published
|
||||
<li>type</li>the type of the the artifact that was published
|
||||
<li>ext</li>the extension of the the artifact that was published
|
||||
<li>resolver</li>the name of the resolver into which the artifact was published
|
||||
<li>file</li>the absolute path of the source file for the artifact
|
||||
<li>overwrite</li>"true" if the new data overwrote existing artifacts, "false" otherwise
|
||||
<li>status</li>"successful" if the artifact published successfully; "failed" if the artifact failed to publish, or if the status is unknown
|
||||
</ul>
|
||||
</td>
|
||||
<td>Fired after an artifact is published into a repository. Note that this event is fired
|
||||
whether or not the publication succeeded. The "status" property can be checked to
|
||||
verify success.</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</td><td>Triggers an ant build.</td></tr>
|
||||
<tr><td>ant-call</td><td>Calls a target in the current ant build.</td></tr>
|
||||
<tr><td>log</td><td>Logs a message on the console or in a log file.</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.settings.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.settings.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>
|
||||
<hr/>
|
||||
<code type="xml">
|
||||
<triggers>
|
||||
<log file="ivy.log"
|
||||
message='downloaded "${origin}" to "${file}" (${duration}ms - ${size}B)'
|
||||
event="post-download-artifact" filter="status=successful"/>
|
||||
</triggers>
|
||||
</code>
|
||||
Logs any successful artifact download, with information on the source and destination, and details on download size and duration.
|
||||
|
||||
The file attribute is optional, the log trigger will output messages to console if it isn't provided.</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> typedef<br/>
|
||||
<br/>
|
||||
Defines a new type in ivy. Useful to define new dependency resolvers, in particular, but also latest strategies.
|
||||
See <a href="../extend.html">how to write and plug your own dependency resolver</a> for details.
|
||||
<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>name</td><td>the name of the type to define. This name is then used as an xml tag.</td>
|
||||
<td>Yes</td></tr>
|
||||
<tr><td>classname</td><td>the fully qualified class name of the type to define.</td>
|
||||
<td>Yes</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
Licensed to the Apache Software Foundation (ASF) under one
|
||||
or more contributor license agreements. See the NOTICE file
|
||||
distributed with this work for additional information
|
||||
regarding copyright ownership. The ASF licenses this file
|
||||
to you under the Apache License, Version 2.0 (the
|
||||
"License"); you may not use this file except in compliance
|
||||
with the License. You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
|
||||
<script type="text/javascript">var xookiConfig = {level: 1};</script>
|
||||
<script type="text/javascript" src="../xooki/xooki.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
<b>Tag:</b> version-matchers
|
||||
|
||||
Defines a list of version matchers. <span class="since">since 1.4</span>
|
||||
|
||||
The child tag used for the version matcher must be equal to a name of a report outputter type (added with the typedef tag).
|
||||
|
||||
A version matcher is used to evaluate if a a dependency version contraint matches a dependency version.
|
||||
|
||||
See <a href="../ivyfile/dependency.html">dependency</a> doc for details about built-in version matchers.
|
||||
|
||||
<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 version matcher</td><td>adds a version matcher to the list of available ones</td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -117,7 +117,7 @@ Three statuses are defined by default in Ivy:
|
|||
A <em>module configuration</em> is a way to use or construct a module. If the same module has different dependencies based on how it's used, those distinct dependency-sets are called its configurations in Ivy.
|
||||
|
||||
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.
|
||||
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 module configurations in ivy.
|
||||
|
||||
For more details on configurations and how they are used in ivy, please refer to the <a href="concept.html">main concepts page</a>.
|
||||
<h1><a name="settings">Ivy Settings</a></h1>
|
||||
|
|
|
|||
62
doc/toc.json
62
doc/toc.json
|
|
@ -52,7 +52,7 @@
|
|||
},
|
||||
{
|
||||
"id":"tutorial/conf",
|
||||
"title":"Using Ivy Configurations",
|
||||
"title":"Using Ivy Module Configurations",
|
||||
"children": [
|
||||
|
||||
]
|
||||
|
|
@ -140,68 +140,68 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration",
|
||||
"id":"settings",
|
||||
"title":"Settings Files",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/property",
|
||||
"id":"settings/property",
|
||||
"title":"property",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/properties",
|
||||
"id":"settings/properties",
|
||||
"title":"properties",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/conf",
|
||||
"id":"settings/settings",
|
||||
"title":"settings",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/include",
|
||||
"id":"settings/include",
|
||||
"title":"include",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/classpath",
|
||||
"id":"settings/classpath",
|
||||
"title":"classpath",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/typedef",
|
||||
"id":"settings/typedef",
|
||||
"title":"typedef",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/lock-strategies",
|
||||
"id":"settings/lock-strategies",
|
||||
"title":"lock-strategies",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/caches",
|
||||
"id":"settings/caches",
|
||||
"title":"caches",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/caches/cache",
|
||||
"id":"settings/caches/cache",
|
||||
"title":"cache",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/caches/ttl",
|
||||
"id":"settings/caches/ttl",
|
||||
"title":"ttl",
|
||||
"children": [
|
||||
|
||||
|
|
@ -212,44 +212,44 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/latest-strategies",
|
||||
"id":"settings/latest-strategies",
|
||||
"title":"latest-strategies",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/parsers",
|
||||
"id":"settings/parsers",
|
||||
"title":"parsers",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/namespaces",
|
||||
"id":"settings/namespaces",
|
||||
"title":"namespaces",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/namespace",
|
||||
"id":"settings/namespace",
|
||||
"title":"namespace",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/namespace/rule",
|
||||
"id":"settings/namespace/rule",
|
||||
"title":"rule",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/namespace/fromtosystem",
|
||||
"id":"settings/namespace/fromtosystem",
|
||||
"title":"fromsystem / tosystem",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/namespace/src",
|
||||
"id":"settings/namespace/src",
|
||||
"title":"src",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/namespace/dest",
|
||||
"id":"settings/namespace/dest",
|
||||
"title":"dest",
|
||||
"children": [
|
||||
|
||||
|
|
@ -264,11 +264,11 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/macrodef",
|
||||
"id":"settings/macrodef",
|
||||
"title":"macrodef",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/macrodef/attribute",
|
||||
"id":"settings/macrodef/attribute",
|
||||
"title":"attribute",
|
||||
"children": [
|
||||
|
||||
|
|
@ -277,7 +277,7 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/resolvers",
|
||||
"id":"settings/resolvers",
|
||||
"title":"resolvers",
|
||||
"children": [
|
||||
{
|
||||
|
|
@ -353,18 +353,18 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/conflict-managers",
|
||||
"id":"settings/conflict-managers",
|
||||
"title":"conflict-managers",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/modules",
|
||||
"id":"settings/modules",
|
||||
"title":"modules",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/module",
|
||||
"id":"settings/module",
|
||||
"title":"module",
|
||||
"children": [
|
||||
|
||||
|
|
@ -373,18 +373,18 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/outputters",
|
||||
"id":"settings/outputters",
|
||||
"title":"outputters",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/statuses",
|
||||
"id":"settings/statuses",
|
||||
"title":"statuses",
|
||||
"children": [
|
||||
{
|
||||
"id":"configuration/status",
|
||||
"id":"settings/status",
|
||||
"title":"status",
|
||||
"children": [
|
||||
|
||||
|
|
@ -393,14 +393,14 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/triggers",
|
||||
"id":"settings/triggers",
|
||||
"title":"triggers",
|
||||
"children": [
|
||||
|
||||
]
|
||||
},
|
||||
{
|
||||
"id":"configuration/version-matchers",
|
||||
"id":"settings/version-matchers",
|
||||
"title":"version-matchers",
|
||||
"children": [
|
||||
|
||||
|
|
|
|||
|
|
@ -51,9 +51,9 @@ help you configure ivy to find ivy files in one place and artifacts in another.
|
|||
a very first step toward using Ivy in a multi project environment.
|
||||
<li>[[tutorial/multiproject]]</li>
|
||||
a more complex example demonstrating the use of Ant+Ivy in a multi project environment.
|
||||
<li><a href="tutorial/conf.html">Using Ivy Configurations</a></li>
|
||||
<li>[[tutorial/conf]]</li>
|
||||
show how to use configurations in ivy file to define set of artifacts.
|
||||
<li><a href="tutorial/build-repository.html">Building a repository</a></li>
|
||||
<li>[[tutorial/build-repository]]</li>
|
||||
show how to build your own enterprise repository.
|
||||
</ul>
|
||||
</textarea>
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The [[ant:install]] task let you copy a module or a set of modules from one repo
|
|||
|
||||
Fortunately the [[ant:install]] task is here to help: you can use specific settings for your repository maintenance build which will be used to maintain your target enterprise repository. These settings will point to another repository (for instance the maven 2 public repository) so that you will just have to ask Ivy to install the modules you want with a simple command line.
|
||||
|
||||
To demonstrate this we will first use some basic ivy settings files to show how it works, and then we will use the advanced [[configuration/namespaces]] feature to demonstrate how to deal with naming mismatch between the source and target repository.
|
||||
To demonstrate this we will first use some basic ivy settings files to show how it works, and then we will use the advanced [[settings/namespaces]] feature to demonstrate how to deal with naming mismatch between the source and target repository.
|
||||
|
||||
<h1>The project used</h1>
|
||||
The project that we will use is pretty simple.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Nevertheless, the result is not always the expected one, especially concerning t
|
|||
|
||||
This problem is pretty usual when you have an existing repository, and want to benefit from a large public repositories which do not follow the same naming conventions. Or simply because you find the public repository you use as a basis is not consistent enough - why all apache commons module aren't don't use the org.apache.commons organization? For historical reasons. But if you setup your own repository you may not want to suffer from history.
|
||||
|
||||
Fortunately Ivy has a very powerful answer to this kind of problem: [[configuration/namespaces namespaces]].
|
||||
Fortunately Ivy has a very powerful answer to this kind of problem: [[settings/namespaces namespaces]].
|
||||
|
||||
<h1>Using namespaces</h1>
|
||||
If you look at the repository built with the [[tutorial/build-repository/basic previous tutorial]], you will see exactly what we were talking about: all apache commons module use their own name as organization.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
In this first step we use the [[ant:install]] task to install modules from the maven 2 repository to a file system based repository. We first install a module with no dependency, then a module with its dependencies.
|
||||
|
||||
<h1>Basic: ivysettings.xml file used</h1>
|
||||
The ivy settings file that we will use is very simple here. It defines two resolvers, libraries and my-repository. The first one is used as the source, the second one as the destination. In a typical setup the second one would be configured using [[configuration:include included]] settings, used by the development team.
|
||||
The ivy settings file that we will use is very simple here. It defines two resolvers, libraries and my-repository. The first one is used as the source, the second one as the destination. In a typical setup the second one would be configured using [[settings/include included]] settings, used by the development team.
|
||||
|
||||
<code type="xml">
|
||||
<ivysettings>
|
||||
|
|
@ -95,7 +95,7 @@ If you call this target, you will see that Ivy installs not only the hibernate m
|
|||
|
||||
As you can see the installation has failed, if you look at the log you will see that there are missing artifacts on the source repository. This means that you will need to download those artifacts manually, and copy them to your destination repository to complete the installation. Fortunately Ivy use a best effort algorithm during install, so that you have everything installed but the missing artifacts.
|
||||
|
||||
You may also have notice that Ivy has installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we use the "no conflict" [[configuration/conflict-managers conflict manager]] in the ivysettings file.
|
||||
You may also have notice that Ivy has installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we use the "no conflict" [[settings/conflict-managers conflict manager]] in the ivysettings file.
|
||||
|
||||
We do not want to evict any modules because we are building our own repository. Indeed if we get both commons-logging 1.0.2 and 1.0.4 it's because some modules among the transitive dependencies of hibernate depend on 1.0.2 and other on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 would be inconsistent in your own repository (depending on a version you don't have installed). Thus developers using this module directly would run into a problem.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
</head>
|
||||
<body>
|
||||
<textarea id="xooki-source">
|
||||
This tutorial introduces the use of configuration in ivy files. Ivy configurations is indeed a very important concept. Someone even told me one day that using Ivy without using configurations is like eating a good cheese without touching the glass of Chateau Margaux 1976 you have just aside :-)
|
||||
This tutorial introduces the use of module configurations in ivy files. Ivy module configurations is indeed a very important concept. Someone even told me one day that using Ivy without using configurations is like eating a good cheese without touching the glass of Chateau Margaux 1976 you have just aside :-)
|
||||
|
||||
More seriously, configurations in ivy can be better understood as views on your module, and you will see how they can be used efficiently here.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
<textarea id="xooki-source">
|
||||
Ivy comes bundled with some default settings which makes it pretty simple to use in common environment. This tutorial, which is close to a reference documentation, explains what are those default settings and how they can be adjusted to your needs.
|
||||
|
||||
To fully understand the concept of settings and what you can do with them, we suggest reading other tutorial related to settings (like [[tutorial/multiple]] and [[tutorial/dual]]) or the <a href="../configuration.html">settings</a> reference documentation.
|
||||
To fully understand the concept of settings and what you can do with them, we suggest reading other tutorial related to settings (like [[tutorial/multiple]] and [[tutorial/dual]]) or the [[settings]] reference documentation.
|
||||
|
||||
<h1>Concept</h1>
|
||||
This default settings mainly consist of 3 kind of repositories:
|
||||
|
|
@ -209,7 +209,7 @@ Now the last thing you will need in order to properly take advantage of the defa
|
|||
</ivysettings>
|
||||
</code>
|
||||
|
||||
Here you are, you have enough clues to configure that the way you want... check the <a href="../configuration.html">settings documentation</a> to see if what you want to do is possible, and go ahead!
|
||||
Here you are, you have enough clues to configure that the way you want... check the [[settings settings documentation]] to see if what you want to do is possible, and go ahead!
|
||||
</textarea>
|
||||
<script type="text/javascript">xooki.postProcess();</script>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ The file contains four main tags: properties, settings, resolvers and modules.
|
|||
This tag only load some properties for the ivy process in the same manner as ant would do it.
|
||||
<h2>settings</h2>
|
||||
This tag is in charge of initializing some parameters for ivy process. The directory that ivy will use to cache artifacts will be in a sub directory called ivy-cache of the directory containing the ivysettings.xml file itself.
|
||||
The second parameter, tells ivy to use a resolver called "libraries" as its default resolver. More information can be found in the [[configuration settings reference documentation]].
|
||||
The second parameter, tells ivy to use a resolver called "libraries" as its default resolver. More information can be found in the [[settings settings reference documentation]].
|
||||
<h2>resolvers</h2>
|
||||
This tag defines the resolvers to use. Here we have two resolvers defined: "projects" and "libraries".
|
||||
The filesystem resolver called "projects" is able to resolve the internal dependencies by locating them on the local filesystem.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ When the ivy.xml of the modules that you want to order contains a <a href="../iv
|
|||
<span class="since">since 2.0</span> The root and leaf attributes can be a delimited list of modules to use as roots. These modules, and all their dependencies will be included in the build list.
|
||||
|
||||
<span class="since">since 2.0</span> By default, all the modules included in a circular dependency are grouped together so that any dependency of any module in the loop will apear before the modules in the loop. This garantee that if there is a depedendency path between a module A and a module B (but no dependency path from B to A), B will alway apear before A even if A is included in a loop in the provided set of modules to sort.
|
||||
Note that circular dependency can also trigger a failure depending on the value configured in the circularDependencyStrategy of your <a href="../configuration/conf.html#circularDependencyStrategy">settings</a>
|
||||
Note that circular dependency can also trigger a failure depending on the value configured in the circularDependencyStrategy of your <a href="../settings/conf.html#circularDependencyStrategy">settings</a>
|
||||
|
||||
<span class="since">since 2.0</span> When you are specifying root or leaf modules you can limit the resulting list to only direct dependencies of the roots modules or to modules that directly depends on your leaf modules.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
<span class="since">(since 2.0)</span> the configure task is deprecated. Use the <a href="settings.html">setting</a> declaration<br/>
|
||||
|
||||
The configure task is used to configure ivy with an xml settings file.<br/><br/>
|
||||
See <a href="../configuration.html">settings</a> for details about the settings file itself.<br/><br/>
|
||||
See [[settings]] for details about the settings file itself.<br/><br/>
|
||||
<i>Note for developers:<br/>
|
||||
After the call to this task, a reference to the configured ivy instance used by all subsequent ant tasks is put in the ant project, under the id "ivy.instance".</i>
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ An example of use is to publish an Ivy managed module to a maven 2 repository.
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr><td>mapping</td>
|
||||
<td>describes the mapping from an Ivy configuration to a POM scope.<br/>These elements takes two attributes: <ul><li>conf</li> the configuration to map<li>scope</li>the scope to which it should be mapped</ul></td>
|
||||
<td>describes the mapping from an Ivy module configuration to a Maven POM scope.<br/>These elements takes two attributes: <ul><li>conf</li> the configuration to map<li>scope</li>the scope to which it should be mapped</ul></td>
|
||||
<td>0..n</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ This task is meant to publish the current module descriptor together with its de
|
|||
|
||||
All the artifacts must have been created <em>before</em> calling this task. It does not create the artifacts themselves, but expects to find them at the location indicated by the artifacts pattern.
|
||||
|
||||
The target repository is given through the name of a resolver declared in current ivy settings. See <a href="../configuration.html">settings</a> for details about resolver supporting artifact publishing.
|
||||
The target repository is given through the name of a resolver declared in current ivy settings. See [[settings]] for details about resolver supporting artifact publishing.
|
||||
|
||||
It also publishes the delivered ivy file (except if you don't want), and even deliver it, if it has not been done with a previous deliver call or if forcedeliver is set to true. That's why this task takes some parameters useful only for delivery. See the illustration below:
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ The source artifact pattern can be specified either as an attribute on the task
|
|||
<tr><td>update</td><td>true to update ivy file metadata (revision, branch, publication date and status) before publishing, false otherwise. This is usually not necessary when using deliver before publish.</td>
|
||||
<td>No. Defaults to false</td></tr>
|
||||
<tr><td>validate</td><td>true to force ivy files validation against ivy.xsd, false to force no validation</td>
|
||||
<td>No. Defaults to default ivy value (as configured in [[configuration settings file]])</td></tr>
|
||||
<td>No. Defaults to default ivy value (as configured in [[settings settings file]])</td></tr>
|
||||
<tr><td>replacedynamicrev</td><td>true to replace dynmic revisions by static ones in the delivered file, false to avoid this replacement <span class="since">since 1.3</span></td>
|
||||
<td>No. Defaults to true</td></tr>
|
||||
<tr><td>publishivy</td><td>True to publish delivered ivy file, false otherwise</td>
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ Two modes are available:
|
|||
</ul>
|
||||
|
||||
<h2>Concurrency</h2>
|
||||
During resolve, Ivy creates a file in the [[configuration/caches resolution cache]]. The creation of this file is not aimed to support concurrency, meaning that you can't have two concurrent resolve of the same module, in the same resolution cache, with the same resolveId.
|
||||
During resolve, Ivy creates a file in the [[settings/caches resolution cache]]. The creation of this file is not aimed to support concurrency, meaning that you can't have two concurrent resolve of the same module, in the same resolution cache, with the same resolveId.
|
||||
|
||||
<i>Note for developers:
|
||||
After the call to this task, a reference to the module descriptor resolved is put in the ant project under the id <code>"ivy.resolved.descriptor"</code>.</i>
|
||||
|
|
@ -115,7 +115,7 @@ After the call to this task, a reference to the module descriptor resolved is pu
|
|||
|
||||
<tr><td>refresh</td><td>true to force Ivy to resolve dynamic revision in this resolve process, false to use cached resolved revision <span class="since">since 2.0</span></td><td>No. defaults to false</td></tr>
|
||||
|
||||
<tr><td>resolveMode</td><td>the resolve mode to use for this dependency resolution process <span class="since">since 2.0</span></td><td>No. defaults to using the resolve mode set in the [[configuration settings]]</td></tr>
|
||||
<tr><td>resolveMode</td><td>the resolve mode to use for this dependency resolution process <span class="since">since 2.0</span></td><td>No. defaults to using the resolve mode set in the [[settings settings]]</td></tr>
|
||||
|
||||
<tr><td>inline</td><td>true to use inline mode, false to resolve an ivy file <span class="since">since 1.4</span></td><td>No. defaults to false</td></tr>
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
|
||||
The settings declaration is used to configure ivy with an xml settings file.
|
||||
|
||||
See [[configuration Settings Files]] for details about the settings file itself.<br/><br/>
|
||||
See [[settings]] for details about the settings file itself.<br/><br/>
|
||||
|
||||
Multiple settings can be defined in a build script. Every task can reference its own settings.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue