Tag: 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).
since 1.3 Once defined, resolvers can be referenced by their name, using the following syntax:
<resolver ref="alreadydefinedresolver"/>Note that this works only if the resolver has been already defined, and not if it is defined later in the ivyconf file.
| Element | Description | Cardinality |
|---|---|---|
| any resolver | adds a resolver to the list of available resolvers | 1..n |
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 page, or even write your own.
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:
| Name | Type | Description |
|---|---|---|
| IvyRep | Standard | Finds ivy files on ivyrep and artifacts on ibiblio. |
| IBiblio | Standard | Finds artifacts on ibiblio. |
| FileSystem | Standard | This very performant resolver finds ivy files and artifacts in your file system. |
| Url | Standard | Finds ivy files and artifacts in any repository accessible with urls. |
| Vfs | Standard | Finds ivy files and artifacts in any repository accessible with apache commons vfs. |
| ssh | Standard | Finds ivy files and artifacts in any repository accessible with ssh. |
| sftp | Standard | Finds ivy files and artifacts in any repository accessible with sftp. |
| Chain | Composite | Delegates the finding to a chain of sub resolvers. |
| Dual | Composite | Delegates the finding of ivy files to one resolver and of artifacts to another. |
All resolvers of the same type share some common attributes detailed here:
| Attribute | Description | Required | Composite | Standard |
|---|---|---|---|---|
| name | the name which identify the resolver | Yes | Yes | Yes |
| validate | indicates if resolved ivy files should be validated against ivy xsd | No, defaults to call setting | Yes | Yes |
| checkmodified | Indicates if this resolver should check lastmodified date to know if an ivy file is up to date. | No, defaults to ${ivy.resolver.default.check.modified} | No | Yes |
| changingPattern | Indicates for which revision pattern this resolver should check lastmodified date to know if an artifact file is up to date. since 1.4 | No, defaults to none | Yes | Yes |
| changingMatcher | The name of the pattern matcher to use to match a revision against the configured changingPattern. since 1.4 | No, defaults to exactOrRegexp | Yes | Yes |
| alwaysCheckExactRevision | Indicates if this resolver should check the given revision even if it's a special one (like latest.integration). since 1.3 | No, defaults to ${ivy.default.always.check.exact.revision} | No | Yes |
| namespace | The name of the namespace to which this resolver belong since 1.3 | No, defaults to 'system' | Yes | Yes |
| checkconsistency | true to check consistency of module descriptors found by this resolver, false to avoid consistency check since 1.3 | No, defaults to true | No | Yes |
| allownomd | true if the absence of module descriptor (usually an ivy file) is authorised for this resolver, false to refuse modules without module descriptor since 1.4 | No, defaults to true | No (except dual) | Yes |
| checksums | a comma separated list of checksum algorithms to use both for publication and checking since 1.4 | No, defaults to ${ivy.checksums} | No | Yes |
| latest | The name of the latest strategy to use. | No, defaults to 'default' | Yes | Yes |
<resolvers>
<filesystem name="1">
<ivy pattern="${ivy.conf.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="${ivy.conf.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>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).
| Tag | ivyrep |
| Handle latest | yes, at least if the repository server is apache based |
| Handle publish | no |
This resolver usually uses ivyrep to find ivy files and ibiblio to find artifacts.
However it can be configured to use other similar repositories.
Note that if no ivy file is found on ivyrep, then this resolver behaves like ibiblio resolver. Thus it's usually better to use this resolver instead of ibiblio one, which is provided mainly for compatibility reasons.
This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| ivyroot | the root of the ivy repository. | No, defaults to ${ivy.ivyrep.default.ivy.root} |
| ivypattern | a pattern describing the layout of the ivy repository. | No, defaults to ${ivy.ivyrep.default.ivy.pattern} |
| artroot | the root of the artifacts repository. | No, defaults to ${ivy.ivyrep.default.artifact.root} |
| artpattern | a pattern describing the layout of the artifacts repository. | No, defaults to ${ivy.ivyrep.default.artifact pattern} |
<ivyrep name="ivyrep" />A default ivyrep resolver, looking for ivy files on ivyrep and artifacts on ibiblio.
<ivyrep name="ivyrep" ivyroot="http://ivyrep.mycompany.com"/>Looks for ivy files on and ivyrep like web site located at http://ivyrep.mycompany.com.
| Tag | ibiblio |
| Handle latest | yes, at least if the repository server is apache based |
| Handle publish | no |
This resolver usually uses ibiblio to find artifacts.
Prefer the use of ivyrep resolver which adds ivy file handling to this resolver.
since 1.3 Using the m2compatible attribute, you can benefit from maven 2 repository compatibility (convert dots in organisation in slashes, search for poms, use transitive dependencies of poms). This setting also affects the default place where the resolver look for its artifacts to point to the maven2 repository. So setting this attribute to true is sufficient to use maven 2 ibiblio repository.
since 1.4 When using the m2compatible flag, you can disable the use of poms by setting the usepoms flag to false. It is then roughly equivalent to an url resolver configured like this:
<url name="test" m2compatible="true">
<artifact pattern="http://www.ibiblio.org/maven2/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
</url>This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| root | the root of the artifacts repository. | No, defaults to ${ivy.ibiblio.default.artifact.root} |
| pattern | a pattern describing the layout of the artifacts repository. | No, defaults to ${ivy.ibiblio.default.artifact.pattern} |
| m2compatible | True if this resolver should be maven2 compatible, false otherwise since 1.3 | No, defaults to false |
| usepoms | True if this resolver should use maven poms when it is already in m2compatible mode, false otherwise since 1.4 | No, defaults to true |
| Tag | filesystem |
| Handle latest | yes |
| Handle publish | yes |
This resolver uses the file system to resolve ivy files and artifacts. It presents the advantage to usually have very good performances. Moreover, it is easy to setup using basic OS file sharing mechanism.
The configuration of such a resolver is mainly done through ivy and artifact patterns, indicating where ivy files and artifacts can be found in the file system. You can indicate a list of pattern which will be checked one after the other.
since 1.3 Using the m2compatible attribute, this resolver will convert dots found in organisation in slashes like maven2 does for groupId. For instance, it will transform the organisation from 'com.company' into 'com/company' when replacing the token [organisation] in your pattern.
This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| m2compatible | True if this resolver should be maven2 compatible, false otherwise since 1.3 | No, defaults to false |
| local | True if this resolver should be considered local, false otherwise since 1.4. See useOrigin attribute on the resolve task for details. | No, defaults to true |
| Element | Description | Cardinality |
|---|---|---|
| ivy | defines a pattern for ivy files, using the pattern attribute | 0..n |
| artifact | defines a pattern for artifacts, using the pattern attribute | 1..n |
| Tag | url |
| Handle latest | yes with http urls (and apache server) and with file urls, no with other urls |
| Handle publish | no |
This resolver is one of the most generic, in fact most of the previous resolvers can be obtained by a particular configuration of this one. Indeed it uses urls to find ivy files and artifacts. The urls it uses are defined through ivy and artifact children, each giving a pattern to find ivy files or artifacts.
This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| m2compatible | True if this resolver should be maven2 compatible, false otherwise since 1.3 | No, defaults to false |
| Element | Description | Cardinality |
|---|---|---|
| ivy | defines a pattern for ivy files, using the pattern attribute | 0..n |
| artifact | defines a pattern for artifacts, using the pattern attribute | 1..n |
<url name="two-patterns-example">
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact].[ext]" />
</url>Looks for ivy files in one place and for artifacts in two places: with or without revision in name (revision being already in the directory structure).
| Tag | chain |
| Handle latest | depends on sub resolvers |
| Handle publish | delegates to first sub resolver in chain |
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.
This resolver shares the common attributes of composite resolvers.
| Attribute | Description | Required |
|---|---|---|
| returnFirst | true if the first found should be returned. | No, defaults to false |
| dual | true if the chain should behave like a dual chain. since 1.3 | No, defaults to false |
| Element | Description | Cardinality |
|---|---|---|
| any resolver | a sub resolver to use | 1..n |
<chain name="test">
<filesystem name="1">
<ivy pattern="${ivy.conf.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="${ivy.conf.dir}/1/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</filesystem>
<ivyrep name="2"/>
</chain>Both a filesystem and ivyrep will be used to look for ivy files. If a dynamic revision is required, then both the filesystem and ivyrep will be queried to find the most recent revision among the two resolvers. Once the most recent revision is found in one resolver, it's the same resolver which will be used to download artifacts.
<chain name="test" returnFirst="true">
<filesystem name="1">
<ivy pattern="${ivy.conf.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="${ivy.conf.dir}/1/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</filesystem>
<ivyrep name="2"/>
</chain>Same as before, except that if a revision is found in the filesystem then ivyrep will not be queried: its the filesystem which will be used for both the ivy file and the artifacts.
<chain name="test" dual="true">
<filesystem name="1">
<ivy pattern="${ivy.conf.dir}/1/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="${ivy.conf.dir}/1/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</filesystem>
<ivyrep name="2"/>
</chain>Same as first example, except that once a module is found by either filesystem or ivyrep, then it's the whole chain which will be queried to download the artifacts. So in this case ivy file and artifacts may be split across the two resolvers for the same module.
| Tag | dual |
| Handle latest | depends on sub resolvers |
| Handle publish | delegates to ivy sub resolver if artifact to publish is of "ivy" type, to artifact sub resolver otherwise |
| Attribute | Description | Required |
|---|---|---|
| allownomd | true if the absence of module descriptor (usually an ivy file) is authorised for this resolver, false to refuse modules without module descriptor since 1.4 | No, defaults to true |
| Element | Description | Cardinality |
|---|---|---|
| any resolver | two resolvers, the first being the ivy resolver, the second the artifact resolver | 2 |
| Tag | sftp |
| Handle latest | yes |
| Handle publish | yes |
This resolver can be used when your ivy repository is located on a server accessible via sftp. The secured nature of sftp and its wide spread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. since 1.4
If your server supports ssh but not sftp, there is also an ssh resolver.
Note that sftp is also supported by vfs, so you can use a vfs resolver instead. The advantage of this resolver is that you have a better control over authentication, it can prompt for username/password credentials, or you can use private/public key authentication, which is not possible with the vfs resolver. When it prompts for username/password, it uses a Swing dialog, which is not possible in a headless environment. If you want to prompt for the credentials on the command line, use ant input task for example before calling ivy.
All necessary connection parameters can be set here via attributes.
However all attributes defined in the pattern url of the resolver will have higher priority and will overwrite the values given here. To specify connection parameters in the pattern, you have to specify a full url and not just a path as pattern.
e.g. pattern="/path/to/my/repos/[artifact].[ext]" will use all connection parameters from this class
e.g. pattern="sftp://myserver.com/path/to/my/repos/[artifact].[ext]" will use all parameters from the attributes with the exception of the host, which will be "myserver.com"
e.g. pattern="sftp://user:geheim@myserver.com:8022/path/to/my/repos/[artifact].[ext]" will use only the keyFile and keyFilePassword from the attributes (if needed). Rest will come from the url.
Note that the authentication features of this resolver are exactly the same as the ssh resolver. Choosing between the two is often a matter of server implementation. If your server supports sftp, usually it's preferrable.
Internally this resolver relies on jsch as ssh client, which is a popular java ssh client, used for example in eclipse.
This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| user | The username to provide as credential | No, defaults to username given on the patterns, or prompt if none is set |
| userPassword | The password to provide as credential | No, defaults to password given on the patterns, or prompt if none is set |
| keyFile | Path to the keyfile to use for authentication | No, defaults to username/password authentication |
| keyFilePassword | the password used to protect the key file | No, will prompt for password if keyFile authentication is used and if it is password encrypted |
| host | The host to connect to | No, defaults to host given on the patterns, fail if none is set |
| port | The port to connect to | No, defaults to 22 |
| Element | Description | Cardinality |
|---|---|---|
| ivy | defines a pattern for ivy files, using the pattern attribute | 0..n |
| artifact | defines a pattern for artifacts, using the pattern attribute | 1..n |
<sftp user="myuser" host="myhost.com">
<ivy pattern="/path/to/ivy/[module]/ivy.xml"/>
<artifact pattern="/path/to/[organisation]/[module]/[artifact].[ext]"/>
</sftp> Will connect to myhost.com using myuser and prompt for the password.
<sftp user="${myuser}" userPassword="${my.password}" host="myhost.com">
<ivy pattern="path/to/ivy/[module]/ivy.xml"/>
<artifact pattern="path/to/[organisation]/[module]/[artifact].[ext]"/>
</sftp>Will connect to myhost.com using user and password provided with ivy variables.
<sftp>
<ivy pattern="sftp://user:geheim@yourserver.com:8022/path/to/repos/[module]/[revision]/ivy.xml"/>
<artifact pattern="sftp://user:secret@myserver.com:8022/path/to/my/repos/[artifact].[ext]"/>
</sftp>Will connect to yourserver.com on port 8022 with user 'user' and password 'geheim' for authentication for ivy files, and to myserver.com on port 8022 using user 'user' and password 'secret' for the artifacts.
<sftp keyFile="path/to/key/file" keyFilePassword="${password}">
<ivy pattern="sftp://user@yourserver.com:8022/path/to/repos/[module]/[revision]/ivy.xml"/>
<artifact pattern="sftp://user@myserver.com:8022/path/to/my/repos/[artifact].[ext]"/>
</sftp>Will connect to yourserver.com on port 8022 with user 'user' and use keyFile path/to/key/file for keyFile and the value of password variable for keyFilePassword authentication for ivy files, and to myserver.com on port 8022 using user 'user' with the same keyFile/keyFilePassword pair for the artifacts.
| Tag | ssh |
| Handle latest | yes |
| Handle publish | yes |
This resolver can be used when your ivy repository is located on a server accessible via ssh. The secured nature of ssh and its wide spread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. since 1.4
If your server supports sftp, you can consider using the sftp resolver.
Internally this resolver shares most of its behaviour with the sftp resolver, so refer to its documentation for details.
This resolver shares the common attributes of standard resolvers.
| Attribute | Description | Required |
|---|---|---|
| user | The username to provide as credential | No, defaults to username given on the patterns, or prompt if none is set |
| userPassword | The password to provide as credential | No, defaults to password given on the patterns, or prompt if none is set |
| keyFile | Path to the keyfile to use for authentication | No, defaults to username/password authentication |
| keyFilePassword | the password used to protect the key file | No, will prompt for password if keyFile authentication is used and if it is password encrypted |
| host | The host to connect to | No, defaults to host given on the patterns, fail if none is set |
| port | The port to connect to | No, defaults to 22 |
| Element | Description | Cardinality |
|---|---|---|
| ivy | defines a pattern for ivy files, using the pattern attribute | 0..n |
| artifact | defines a pattern for artifacts, using the pattern attribute | 1..n |
<ssh user="myuser" host="myhost.com">
<ivy pattern="/path/to/ivy/[module]/ivy.xml"/>
<artifact pattern="/path/to/[organisation]/[module]/[artifact].[ext]"/>
</ssh> Will connect to myhost.com using myuser and prompt for the password.
<ssh keyFile="path/to/key/file" keyFilePassword="${password}">
<ivy pattern="ssh://user:geheim@yourserver.com:8022/path/to/repos/[module]/[revision]/ivy.xml"/>
<artifact pattern="ssh://user:geheim@myserver.com:8022/path/to/my/repos/[artifact].[ext]"/>
</ssh>Will connect to yourserver.com on port 8022 with user geheim and use keyFile path/to/key/file for keyFile and the value of password variable for keyFilePassword authentication for ivy files, and to myserver.com on port 8022 using user geheim with the same keyFile/keyFilePassword pair for the artifacts.
| Tag | vfs |
| Handle latest | depend on vfs capacity, usually yes |
| Handle publish | depend on vfs capacity, usually yes |
This resolver is certainly the most capable, since it relies on Apache commons VFS, which gives an uniform access to a good number of file systems, including ftp, webdav, zip, ... since 1.4
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
This resolver shares the common attributes of standard resolvers.
| Element | Description | Cardinality |
|---|---|---|
| ivy | defines a pattern for ivy files, using the pattern attribute | 0..n |
| artifact | defines a pattern for artifacts, using the pattern attribute | 1..n |
<vfs name="vfs-resolver">
<ivy pattern="sftp://username:password@host/[organisation]/[module]/[revision]/ivy.xml" />
<artifact pattern="sftp://username:password@host/[organisation]/[module]/[revision]/[artifact].[ext]" />
</vfs> Access ivy and artifacts files using sftp.