http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/dependency.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/dependency.adoc b/asciidoc/ivyfile/dependency.adoc index b64548e..241f44a 100644 --- a/asciidoc/ivyfile/dependency.adoc +++ b/asciidoc/ivyfile/dependency.adoc @@ -26,11 +26,11 @@ Declares a dependency for this module. A dependency is described by the module o The revision can be given as a fixed one (1.5.2, for instance) or as a latest (or dynamic) one. Several possibilities for dynamic revisions are implemented in Ivy: * `latest.integration` + - selects the latest revision of the dependency module. +selects the latest revision of the dependency module. * `latest.[any status]` *__since 1.4__* + - selects the latest revision of the dependency module with at least the specified status. + -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. +selects the latest revision of the dependency module with at least the specified status. + +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 link:../settings/statuses.html[statuses] to see how to configure module statuses. * end the revision with a `+` + @@ -50,13 +50,13 @@ Examples: + `(,2.0[` matches all versions lower than 2.0 + *__since 1.4__* If you don't find a way to expression your dependency version constraint among these, you can link:../settings/version-matchers.html[plug your own]. -The way to determine which revision is the "latest" between two is configurable through the use of pluggable LatestStrategy. See link:../reference.html[ivy main concepts] for details about this. +The way to determine which revision is the "latest" between two is configurable through the use of pluggable LatestStrategy. See link:../reference.html[Ivy main concepts] for details about this. == [[revision-constraint]]Revision constraint *__since 2.0__* The `dependency` tag supports two revision attributes: `rev`, corresponding to the default required dependency revision, and `revConstraint`, corresponding to a dynamic revision constraint applied on this dependency. -Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a static version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This both ensure better metadata in the repository while still allowing easier build reproducibility. +Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a static version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This ensures better metadata in the repository while still allowing easier build reproducibility. == Configurations mapping @@ -68,11 +68,11 @@ The first way to declare this mapping is called the inline mapping. It is maybe === Specify one configuration name -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 link:../ivyfile/configurations.html[configurations] for details, or table below for examples). +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 link:../ivyfile/configurations.html[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. -The link:../ivyfile/configurations.html#defaultconfmapping[examples on the dependency on the configurations page] explain how ivy interprets the conf attribute according to how link:../ivyfile/configurations.html[defaultconfmapping] and link:../ivyfile/configurations.html[defaultconf] is set. +The link:../ivyfile/configurations.html#defaultconfmapping[examples on the dependency on the configurations page] explain how Ivy interprets the conf attribute according to how link:../ivyfile/configurations.html[defaultconfmapping] and link:../ivyfile/configurations.html[defaultconf] is set. === Specify a configuration mapping using the `$$->$$` operator @@ -91,13 +91,13 @@ Note that you can use the wildcard `$$*$$` as a configuration name, meaning that *__since 1.4__* `#` can be used as right side operand to mean _this_ configuration, and thus refers to the configuration being resolved. It is slightly similar to `@`, except that it takes into account the configuration being actually resolved in case of a configuration extending another one. -Example: Let's foo be a module with two configurations, A and B, B extending A. Then a dependency declaring conf `$$A->#$$` will get A dep conf in its confs A (when resolving A, ivy will find interpret the `#` symbol as A) and B dep conf in its conf B (when resolving B, ivy will interpret the `#` symbol as B, even if this dependency is only required because of the A dependency). +Example: Let's foo be a module with two configurations, A and B, B extending A. Then a dependency declaring conf `$$A->#$$` will get A dep conf in its confs A (when resolving A, Ivy will find interpret the `#` symbol as A) and B dep conf in its conf B (when resolving B, Ivy will interpret the `#` symbol as B, even if this dependency is only required because of the A dependency). If you don't understand really how this works, do not use it :-) *__since 1.4__* `%` can be used as left side operand to mean "all the other configurations". This can be useful when you only have a specific mapping for some configurations and a default mapping for all the others. For instance, `$$test->runtime;%->default$$` means that the `test` configuration is mapped to the `runtime` configuration, but all the other configurations are mapped to the `default` configuration. -*__since 1.3__* a fallback mechanism can be used when you are not sure that the dependency will have the required conf. You can indicate to ivy that you want one configuration, but if it isn't present, use another one. +*__since 1.3__* a fallback mechanism can be used when you are not sure that the dependency will have the required conf. You can indicate to Ivy that you want one configuration, but if it isn't present, use another one. The syntax for specifying this adds the fallback conf between parenthesis right after the required conf. For instance, `$$test->runtime(default)$$` means that in the test configuration of the module the `runtime` conf of the dependency is required, but if doesn't exist, it will use the `default` conf instead. If `default` conf doesn't exist then it will be considered as an error. Note that the `*` wildcard can be used as fallback conf. @@ -174,8 +174,8 @@ See link:../ivyfile/conflicts.html[conflicts manager] for details. |======= |Element|Description|Cardinality |link:../ivyfile/dependency-conf.html[conf]|defines configuration mapping has sub element|0..n -|link:../ivyfile/dependency-artifact.html[artifact / include]|defines artifacts inclusion - use only if you do not control dependency ivy file|0..n -|link:../ivyfile/artifact-exclude.html[exclude]|defines artifacts exclusion - use only if you do not control dependency ivy file|0..n +|link:../ivyfile/dependency-artifact.html[artifact / include]|defines artifacts inclusion - use only if you do not control dependency Ivy file|0..n +|link:../ivyfile/artifact-exclude.html[exclude]|defines artifacts exclusion - use only if you do not control dependency Ivy file|0..n |======= == Examples
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/description.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/description.adoc b/asciidoc/ivyfile/description.adoc index 35af9a0..2d937f7 100644 --- a/asciidoc/ivyfile/description.adoc +++ b/asciidoc/ivyfile/description.adoc @@ -20,7 +20,7 @@ *Tag:* description *Parent:* link:../ivyfile/info.html[info] Describes the current module. This tag is the only one which can contain free text, -including html. It is used to describe the module itself, usually in a single short phrase +including HTML. It is used to describe the module itself, usually in a single short phrase (it is not meant to replace the module description on the corresponding web site), and then gives all information necessary to use the module, especially information about public configurations, how and when to use them. @@ -30,5 +30,5 @@ public configurations, how and when to use them. [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|homepage|the url of the homepage of the module|No, but it's recommended to indicate it. +|homepage|the URL of the homepage of the module|No, but it's recommended to indicate it. |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/exclude.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/exclude.adoc b/asciidoc/ivyfile/exclude.adoc index 0f68454..60d3057 100644 --- a/asciidoc/ivyfile/exclude.adoc +++ b/asciidoc/ivyfile/exclude.adoc @@ -19,7 +19,7 @@ *Tag:* exclude *Parent:* link:../ivyfile/dependencies.html[dependencies] -*__since 2.0__* This feature gives you more control on a dependency for which you do not control its ivy file. +*__since 2.0__* This feature gives you more control on a dependency for which you do not control its Ivy file. It allows to exclude artifacts, modules or organizations from the list of dependencies for the whole module. It is very similar to the link:../ivyfile/artifact-exclude.html[dependency exclude] element, except that it applies to a whole module, which can be very useful when a lot of dependencies transitively bring a module you don't want. @@ -34,7 +34,7 @@ It is very similar to the link:../ivyfile/artifact-exclude.html[dependency exclu |artifact|the name of an artifact of the dependency module to add to the exclude list, or an expression matching this name (see `matcher` attribute below)|No, defaults to `$$*$$` |type|the type of the artifact of the dependency module to add to the exclude list, or a regexp matching this name|No, defaults to `$$*$$` |ext|the extension of the artifact of the dependency module to add to the exclude list, or an expression matching this name (see `matcher` attribute below)|No, defaults to the value of `type` -|matcher|the link:../concept.html#matcher[matcher] to use to match the modules to excludes|No, defaults to `exactOrRegexp` in pre 1.3 ivy files, and `exact` in 1.3 and superior +|matcher|the link:../concept.html#matcher[matcher] to use to match the modules to excludes|No, defaults to `exactOrRegexp` in pre 1.3 Ivy files, and `exact` in 1.3 and superior |conf|comma separated list of the master configurations in which this artifact should be included. `$$*$$` wildcard can be used to designate all configurations of this module|No, defaults to `$$*$$`, unless nested conf are specified http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/include.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/include.adoc b/asciidoc/ivyfile/include.adoc index ee31883..eaabc6f 100644 --- a/asciidoc/ivyfile/include.adoc +++ b/asciidoc/ivyfile/include.adoc @@ -21,11 +21,11 @@ Include configurations specified in another file. *__since 1.3__* -The included file should have a `configurations` tag as root tag, which follow the same specification as the link:../ivyfile/configurations.html[configurations] tag of the ivy file. +The included file should have a `configurations` tag as root tag, which follow the same specification as the link:../ivyfile/configurations.html[configurations] tag of the Ivy file. This means that it can contain conf declarations, other file inclusion, and also a `defaultconfmapping`. -When delivering an ivy file with such an inclusion, the included configuration file is inlined, i.e. ivy remove the dependency on the external file. +When delivering an Ivy file with such an inclusion, the included descriptor file is inlined, i.e. Ivy removes the dependency on the external file. == Attributes http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/ivyauthor.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/ivyauthor.adoc b/asciidoc/ivyfile/ivyauthor.adoc index 282c5bc..ef2337c 100644 --- a/asciidoc/ivyfile/ivyauthor.adoc +++ b/asciidoc/ivyfile/ivyauthor.adoc @@ -19,7 +19,7 @@ *Tag:* ivyauthor *Parent:* link:../ivyfile/info.html[info] -Gives information about who has contributed to write this ivy file. It does NOT indicate who +Gives information about who has contributed to write this Ivy file. It does NOT indicate who is the author of the module itself. == Attributes @@ -28,5 +28,5 @@ is the author of the module itself. |======= |Attribute|Description|Required |name|the name of the author, as a person or a company.|Yes -|url|an url pointing to where the author can bea reached.|No, but it's a good practice to indicate it +|url|an URL pointing to where the author can be reached.|No, but it's a good practice to indicate it |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/license.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/license.adoc b/asciidoc/ivyfile/license.adoc index fed2f8c..437bc18 100644 --- a/asciidoc/ivyfile/license.adoc +++ b/asciidoc/ivyfile/license.adoc @@ -27,6 +27,6 @@ Gives information about a license of the described module. |======= |Attribute|Description|Required |name|the name of the license. Try to respect spelling when using a classical license.|Yes -|url|an url pointing to the license text.|No, but it's a good practice to indicate it +|url|an URL pointing to the license text.|No, but it's a good practice to indicate it |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/manager.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/manager.adoc b/asciidoc/ivyfile/manager.adoc index 6424373..b9d376d 100644 --- a/asciidoc/ivyfile/manager.adoc +++ b/asciidoc/ivyfile/manager.adoc @@ -19,7 +19,7 @@ *Tag:* manager *Parent:* link:../ivyfile/conflicts.html[conflicts] -*__(since 2.0)__* the conflicts section is deprecated. Use the link:../ivyfile/conflict.html[conflict] instead. +*__(since 2.0)__* the conflicts section is deprecated. Use link:../ivyfile/conflict.html[conflict] instead. Specify a a conflict manager for one or several dependencies. @@ -41,5 +41,5 @@ See link:../ivyfile/conflicts.html[Conflicts Manager] for details on conflicts m |name|the name of the conflict manager to use .2+.^|Exactly one of two |rev|a comma separated list of revisions this conflict manager should select -|matcher|the link:../concept.html#matcher[matcher] to use to match the modules for which the conflict manager should be used *__since 1.3__*|No, defaults to `exactOrRegexp` in pre 1.3 ivy files, and `exact` in 1.3 and superior +|matcher|the link:../concept.html#matcher[matcher] to use to match the modules for which the conflict manager should be used *__since 1.3__*|No, defaults to `exactOrRegexp` in pre 1.3 Ivy files, and `exact` in 1.3 and superior |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/override.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/override.adoc b/asciidoc/ivyfile/override.adoc index 38330be..03797ae 100644 --- a/asciidoc/ivyfile/override.adoc +++ b/asciidoc/ivyfile/override.adoc @@ -23,9 +23,9 @@ Specify an override mediation rule, overriding the revision and/or branch requested for a transitive dependency. -This can be useful when a direct dependency is bringing a transitive dependency for which you want to change the revision, without actually declaring a dependency on it (because the module doesn't actually depend on it) and without using conflict management for this purpose (maybe because there is no conflict at all, or because you want to by pass conflict management for this particular transitive dependency). +This can be useful when a direct dependency is bringing a transitive dependency for which you want to change the revision, without actually declaring a dependency on it (because the module doesn't actually depend on it) and without using conflict management for this purpose (maybe because there is no conflict at all, or because you want to bypass conflict management for this particular transitive dependency). -Overriding is done before any else, in a phase called dependency descriptor mediation. The transitive dependency then behave exactly as if it were declared with the new value. +Overriding is done before any else, in a phase called dependency descriptor mediation. The transitive dependency then behaves exactly as if it were declared with the new value. Note that even though no attribute is required, it makes no sense to set no attributes at all. It would mean that overriding is triggered for all transitive dependencies, but doesn't override anything. Most of the time, at least org or module should be set to override only a subset of transitive dependencies, and at least branch or rev should be set to actually override something. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/ivyfile/repository.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/ivyfile/repository.adoc b/asciidoc/ivyfile/repository.adoc index 9a339b8..e900791 100644 --- a/asciidoc/ivyfile/repository.adoc +++ b/asciidoc/ivyfile/repository.adoc @@ -27,8 +27,8 @@ Gives information about a public repository where the module can be found. This |======= |Attribute|Description|Required |name|the name of the repository. Try to respect spelling for common repositories (ibiblio, ivyrep, ...)|Yes -|url|an url pointing to the repository.|Yes -|pattern|an ivy pattern to find modules on this repository|No, but it's recommended to indicate it. -|ivys|`true` if ivy file can be found on this repository|No, defaults to `false`. +|url|an URL pointing to the repository.|Yes +|pattern|an Ivy pattern to find modules on this repository|No, but it's recommended to indicate it. +|ivys|`true` if Ivy file can be found on this repository|No, defaults to `false`. |artifacts|`true` if module artifacts can be found on this repository|No, defaults to `false`. |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/js/jquery.treeview.js ---------------------------------------------------------------------- diff --git a/asciidoc/js/jquery.treeview.js b/asciidoc/js/jquery.treeview.js index 0a5f251..b218a7c 100644 --- a/asciidoc/js/jquery.treeview.js +++ b/asciidoc/js/jquery.treeview.js @@ -17,7 +17,7 @@ * The "treeview" class is added if not already present. * * To hide branches on first display, mark their li elements with - * the class "closed". If the "collapsed" option is used, mark intially open + * the class "closed". If the "collapsed" option is used, mark initially open * branches with class "open". * * @example .treeview, .treeview ul { http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/moreexamples.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/moreexamples.adoc b/asciidoc/moreexamples.adoc index ee3b633..015a227 100644 --- a/asciidoc/moreexamples.adoc +++ b/asciidoc/moreexamples.adoc @@ -22,27 +22,27 @@ If you have successfully followed and understood all the tutorials, you still mi Here are some links which might be interesting: -== link:http://wiki.hippo.nl/display/OS/SAnt+build+system[SAnt] +== SAnt -SAnt is an experimental build system based on Ant and Ivy. It can be interesting to use "as is", or to get insight on an interesting approach to manage your builds. +link:http://wiki.hippo.nl/display/OS/SAnt+build+system[SAnt] is an experimental build system based on Ant and Ivy. It can be interesting to use "as is", or to get insight on an interesting approach to manage your builds. -== link:https://springmodules.dev.java.net/[Spring Modules] +== Spring Modules -The spring modules project build system is based on Ant and Ivy, and it's really interesting to have a look at how a modularized project can take advantage of advanced Ant and Ivy features to make the build simpler. +The link:https://springmodules.dev.java.net/[Spring Modules] project build system is based on Ant and Ivy, and it's really interesting to have a look at how a modularized project can take advantage of advanced Ant and Ivy features to make the build simpler. -== link:http://www.opensymphony.com/webwork/[Webwork] +== Webwork -The webwork project (which should become struts action framework) uses ant+ivy for their build, and thus makes their framework very easy to use in an ant+ivy build system. They have a link:http://wiki.opensymphony.com/display/WW/Dependencies[page documenting how to use Ivy with their framework], which can be an interesting reading, even if you don't plan to use webwork. +The link:http://www.opensymphony.com/webwork/[Webwork project] (which became Struts Action framework) uses Ant+Ivy for their build, and thus makes their framework very easy to use in an Ant+Ivy build system. They have a link:http://wiki.opensymphony.com/display/WW/Dependencies[page documenting how to use Ivy with their framework], which can be an interesting reading, even if you don't plan to use Webwork. -== link:http://www.jaya.free.fr/ivy/doc/articles/ease-multi-module.html[Easing multi-module development] +== Easing multi-module development -Johan stuyts, the author of SAnt, also contributed a nice article on his view of how to use Ivy on a multi-module environment. +Johan Stuyts, the author of SAnt, also contributed link:http://www.jaya.free.fr/ivy/doc/articles/ease-multi-module.html[a nice article] on his view of how to use Ivy on a multi-module environment. -== link:http://olmex.blogspot.in/2012/04/ivy-beginners-guide.html[Beginners Guide] +== Beginners Guide -Apache Ivy - Beginners Guide is a step by step guide to assist beginners in understanding basic concepts/tasks and use them straight away in their projects either through Ant build or in Eclipse IDE. +link:http://olmex.blogspot.in/2012/04/ivy-beginners-guide.html[Apache Ivy - Beginners Guide] is a step by step guide to assist beginners in understanding basic concepts/tasks and use them straight away in their projects either through Ant build or in Eclipse IDE. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi.adoc b/asciidoc/osgi.adoc index 34ca660..5609ea6 100644 --- a/asciidoc/osgi.adoc +++ b/asciidoc/osgi.adoc @@ -34,7 +34,7 @@ So with a standard ivy.xml, you can express some dependency on some OSGi bundle With OSGi we can declare different kind of capabilities of a bundle which can match different kind of requirements of some other bundles (`Require-Bundle`/`Bundle-SymbolicName`, `Import-Package`/`Export-Package`, `Import-Service`/`Export-Service`). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involving OSGi dependencies management. -Details on the mapping of the OSGi dependency model into Ivy's one can be found in that link:osgi/osgi-mapping.html[page]. +Details on the mapping of the OSGi dependency model into Ivy's one can be found in this link:osgi/osgi-mapping.html[page]. == Repository descriptor based resolvers http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi/eclipse-plugin.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi/eclipse-plugin.adoc b/asciidoc/osgi/eclipse-plugin.adoc index a2e8e0d..0d142f0 100644 --- a/asciidoc/osgi/eclipse-plugin.adoc +++ b/asciidoc/osgi/eclipse-plugin.adoc @@ -23,7 +23,7 @@ ==== Note that this feature is considered as *experimental*. -It should work with simple configuration but may not in complex ones. If you have any issue with that feature, you are welcomed to come discuss your use case on the link:http://ant.apache.org/ivy/mailing-lists.html[ivy-user] mailing list, or discuss about implementation issues or improvement you may have found, on link:http://ant.apache.org/ivy/mailing-lists.html[ant-dev]. +It should work with a simple configuration but may not with complex ones. If you have any issue with that feature, you are welcomed to come discuss your use case on the link:http://ant.apache.org/ivy/mailing-lists.html[ivy-user] mailing list, or discuss about implementation issues or improvement you may have found, on link:http://ant.apache.org/ivy/mailing-lists.html[ant-dev]. ==== @@ -33,7 +33,7 @@ This page describes how to build an Eclipse™ plugin with Apache Ivy™ a == Quick setup -In few steps, we will setup a build to compile and package an Eclipse plugin. +In a few steps, we will set up a build to compile and package an Eclipse plugin. * download this link:../samples/eclipse-plugin/ivy.xml[ivy.xml], this link:../samples/eclipse-plugin/ivysettings.xml[ivysettings.xml], this link:../samples/eclipse-plugin/ivysettings.properties[ivysettings.properties], this link:../samples/eclipse-plugin/build.xml[build.xml], and put them into your plugin folder @@ -93,6 +93,6 @@ When building an Eclipse plugin, we are relying on a "target platform", the Ecli Ivy needs an aggregation of the OSGi metadata in order to resolve a such repository. The Ant task link:../use/buildobr.html[buildobr] builds a OBR (OSGi Bundle Repository) descriptor file from a set of OSGi bundles. So here we are using this Ant task to gather OSGi metadata from the Eclipse plugins in the "target platform". In the above example, the file is built in `target/repo-eclipse.xml`. -The plugin to be built has a `ivy.xml` file describing its dependencies to be used by Ivy. Since the actual dependencies are in the `MANIFEST.MF` file, in the `ivy.xml` file we specify that it extends `META-INF/MANIFEST.MF`. So there not much dependencies specified in the `ivy.xml`. But as Ivy doesn't support the `Bundle-Fragment` OSGi feature, the `ivy.xml` can help specify the missing dependencies. +The plugin to be built has a `ivy.xml` file describing its dependencies to be used by Ivy. Since the actual dependencies are in the `MANIFEST.MF` file, in the `ivy.xml` file we specify that it extends `META-INF/MANIFEST.MF`. So there are few dependencies specified in the `ivy.xml`. But as Ivy doesn't support the `Bundle-Fragment` OSGi feature, the `ivy.xml` can help specify the missing dependencies. -Having this setup, it is then a standard Ant+Ivy build. Ivy computes the classpath to be then used by the `javac` tasks. Note that `javac` is not aware of the OSGi metadata and is then incapable of failing to compile if private packages are accessed. +Having this setup, it is then a standard Ant+Ivy build. Ivy computes the classpath to be used by the `javac` tasks. Note that `javac` is not aware of the OSGi metadata and is then incapable of failing to compile if private packages are accessed. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi/osgi-mapping.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi/osgi-mapping.adoc b/asciidoc/osgi/osgi-mapping.adoc index ccba816..51bc030 100644 --- a/asciidoc/osgi/osgi-mapping.adoc +++ b/asciidoc/osgi/osgi-mapping.adoc @@ -103,7 +103,7 @@ So OSGi capabilities of bundles in a repo will be gathered directly from the man === Export-Package -Exported package, are declaring capabilities of the bundle in term of package. But they also declare dependencies between the declared package via the parameter `use`. These dependencies have to be declared in the ivy.xml. And we will use Ivy link:../terminology.html#configurations[module configurations] for that. +Exported packages are declaring capabilities of the bundle in term of packages. But they also declare dependencies between the declared package via the parameter `use`. These dependencies have to be declared in the ivy.xml. And we will use Ivy link:../terminology.html#configurations[module configurations] for that. First, each exported package will be declared in the ivy.xml as a configuration. The name of the configuration will start will `use_` and will end with the name of that package. @@ -137,7 +137,7 @@ a| == OSGi Requirements / Ivy dependencies -In OSGi there are different kind of dependencies, which is an OSGi bundle repository documentation is called a "requirement". The problem is that Ivy understands only one kind of requirement, so we use here some extra attribute to declare those different kind of dependency. +In OSGi there are different kinds of dependencies, which in an OSGi bundle repository documentation is called a "requirement". The problem is that Ivy understands only one kind of requirement, so we use here some extra attribute to declare those different kinds of dependencies. === Require-Bundle @@ -237,4 +237,4 @@ a| Ivy doesn't support the header `Fragment-Host`. -The workaround is to manually specify, as dependencies in the ivy.xml the bundles, which would fit to be the extensions of the host bundle. +The workaround is to manually specify, as dependencies in the ivy.xml, the bundles which would fit to be the extensions of the host bundle. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi/sigil.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi/sigil.adoc b/asciidoc/osgi/sigil.adoc index c8ede8d..062000b 100644 --- a/asciidoc/osgi/sigil.adoc +++ b/asciidoc/osgi/sigil.adoc @@ -25,7 +25,7 @@ Another initiative to manage OSGi™ dependencies is the project link:https:/ == A different approach -Apache Felix Sigil is at its core about managing OSGi dependencies, not directly related to Ivy. Most of it core feature is about the implementation of the not yet released OBR (OSGi Bundle Repository) specification. It then provides integration layers with several tools so that developers can use the OBR API. It provides an Eclipse plugin and there are the Ant/Ivy tasks and resolvers. +Apache Felix Sigil is at its core about managing OSGi dependencies, not directly related to Ivy. Most of its core feature is about the implementation of the not yet released OBR (OSGi Bundle Repository) specification. It then provides integration layers with several tools so that developers can use the OBR API. It provides an Eclipse plugin and there are the Ant/Ivy tasks and resolvers. On the other hand the built-in OSGi capabilities in Ivy are targeted towards users already familiar with Ivy and link:http://ant.apache.org/ivy/links.html[tools around it] like link:http://ant.apache.org/ivy/ivyde[Apache IvyDE™]. So with a minimum amount of effort, they can get OSGi dependency management. @@ -47,6 +47,6 @@ The immediate consequence of this difference is that the built-in resolver is pr === Source of metadata -Apache Felix Sigil has its own format about specifying the OSGi dependencies. Whereas Ivy requires an `ivysettings.xml` and an `ivy.xml`, Sigil requires a `sigil-repos.properties` and a `sigil.properties`. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described in the Sigil quickstart link:https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Sigil+Ivy+Quickstart[here]. +Apache Felix Sigil has its own format for specifying the OSGi dependencies. Whereas Ivy requires an `ivysettings.xml` and an `ivy.xml`, Sigil requires a `sigil-repos.properties` and a `sigil.properties`. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described in the Sigil quickstart link:https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Sigil+Ivy+Quickstart[here]. To support OSGi directly in Ivy, you just need to add an extra namespace in the `ivy.xml`, and in the `ivysettings.xml` just declare the proper resolver and latest revision strategy. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi/standard-osgi.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi/standard-osgi.adoc b/asciidoc/osgi/standard-osgi.adoc index a4ed555..2504830 100644 --- a/asciidoc/osgi/standard-osgi.adoc +++ b/asciidoc/osgi/standard-osgi.adoc @@ -37,7 +37,7 @@ It should work with simple configuration but may not in complex ones. If you hav This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionally one for testing too, and then publish our bundle in a OSGi aware repository. -In oder to produce OSGi metadata of sufficient quality and to avoid maintaining them manually, the link:http://bndtools.org/[bnd] tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the `ivy.xml` file, the `MANIFEST.MF` being generated from the computed classpath. +In order to produce OSGi metadata of sufficient quality and to avoid maintaining them manually, the link:http://bndtools.org/[bnd] tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the `ivy.xml` file, the `MANIFEST.MF` being generated from the computed classpath. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/osgi/target-platform.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/osgi/target-platform.adoc b/asciidoc/osgi/target-platform.adoc index 8103170..11128aa 100644 --- a/asciidoc/osgi/target-platform.adoc +++ b/asciidoc/osgi/target-platform.adoc @@ -23,7 +23,7 @@ ==== Note that this feature is considered as *experimental*. -It should work with simple configuration but may not in complex ones. If you have any issue with that feature, you are welcomed to come discuss your use case on the link:http://ant.apache.org/ivy/mailing-lists.html[ivy-user] mailing list, or discuss about implementation issues or improvement you may have found, on link:http://ant.apache.org/ivy/mailing-lists.html[ant-dev]. +It should work with a simple configuration but may not with complex ones. If you have any issue with that feature, you are welcomed to come discuss your use case on the link:http://ant.apache.org/ivy/mailing-lists.html[ivy-user] mailing list, or discuss about implementation issues or improvement you may have found, on link:http://ant.apache.org/ivy/mailing-lists.html[ant-dev]. ==== @@ -52,7 +52,7 @@ First you need a project (basically a folder) in which you will manage your targ In the build there is a target: `update-dependencies`. This target will do a resolve with the `ivy.xml` and will generate an `ivy-fixed.xml` from the resolved dependencies. This `ivy-fixed.xml` file contains only fixed non transitive dependencies (see the link:../use/fixdeps.html[fixdeps] task for further info). With that `ivy-fixed.xml` file, subsequent dependency resolutions are then reproducible and will always generate the same set of artifacts. -Once generated, it is recommended to share that `ivy-fixed.xml` file into you version control system (subversion, git, etc...). The target `update-dependencies` is then to be launched each time you edit the `ivy.xml`, when you want to change the content of your target platform. +Once generated, it is recommended to share that `ivy-fixed.xml` file into your version control system (Git, Subversion, etc...). The target `update-dependencies` must then be launched each time you edit the `ivy.xml`, when you want to change the content of your target platform. The second target `generate-target-platform` will generate an `obr.xml`, a OSGi Bundle repository descriptor. This file will list every artifact which has been resolved by the `ivy-fixed.xml`. Then each of your bundles you develop will do its resolve against that `obr.xml` (see the link:../resolver/obr.html[obr resolver]). http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/reference.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/reference.adoc b/asciidoc/reference.adoc index c726247..7eb48e8 100644 --- a/asciidoc/reference.adoc +++ b/asciidoc/reference.adoc @@ -32,7 +32,7 @@ This part gives you the meaning of some words used all over the Ivy documentatio ** link:concept.html[Main Concepts] + -This part introduces the main concepts used in Ivy: dependency resolvers, variables, patterns, and also a good introduction to a central ivy concept: module configurations. +This part introduces the main concepts used in Ivy: dependency resolvers, variables, patterns, and explains a central Ivy concept: module configurations. ** link:principle.html[How does it work ?] + @@ -52,12 +52,12 @@ This part is dedicated to the specification of the settings file of Ivy (usually * link:ivyfile.html[Ivy Files] + -This part is the reference for the module descriptors, the Ivy files in which you describe your dependencies. If you have any questions about what can be done or not in an ivy file, you will find the answer here. +This part is the reference for the module descriptors, the Ivy files in which you describe your dependencies. If you have any questions about what can be done or not in an Ivy file, you will find the answer here. * link:ant.html[Ant Tasks] + -This part describes how to use Ivy from ant. It's in this section that all ant tasks provided by Ivy are specified. +This part describes how to use Ivy from Ant. It's in this section that all Ant tasks provided by Ivy are specified. * link:standalone.html[Using standalone] + -Even though Ivy is most often used from ant, it can also be used from the command line. This page describes how you can do this. +Even though Ivy is most often used from Ant, it can also be used from the command line. This page describes how you can do this. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/release-notes.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/release-notes.adoc b/asciidoc/release-notes.adoc index 95d95b4..c00e452 100644 --- a/asciidoc/release-notes.adoc +++ b/asciidoc/release-notes.adoc @@ -28,7 +28,7 @@ configurability, and tight integration with link:https://ant.apache.org/[Apache == Download You can download this release at link:https://ant.apache.org/ivy/download.cgi[] -Issues should either be discussed in the link:https://ant.apache.org/ivy/mailing-lists.html[Ivy user mailing list] or should be reported to at link:https://issues.apache.org/jira/browse/IVY[] +Issues should either be discussed in the link:https://ant.apache.org/ivy/mailing-lists.html[Ivy user mailing list] or reported at link:https://issues.apache.org/jira/browse/IVY[] More information about the project can be found on the website link:https://ant.apache.org/ivy/[] @@ -38,7 +38,7 @@ Key features of this 2.5.0 release are: * The minimum runtime Java version required is now Java 7 * Ivy now uses BouncyCastle 1.52. Due to the non backward compatibility of that library, earlier versions are not supported. - * Ivy now uses HttpComponents HttpClient 4.5.x version for dealing with HTTP backed resolvers. Users are expected to have this version of the library (and its dependencies) in their runtime classpath if they want to use such resolvers. The previous (similarly named but not the same) commons-httpclient client library is no longer used or supported. (jira:IVY-1563[]) + * Ivy now uses HttpComponents HttpClient 4.5.x version when dealing with HTTP backed resolvers. Users are expected to have this version of the library (and its dependencies) in their runtime classpath if they want to use such resolvers. The previous (similarly named but not the same) commons-httpclient library is no longer used or supported. (jira:IVY-1563[]) == List of Changes in this Release @@ -48,7 +48,7 @@ For details about the following changes, check our JIRA install at link:https:// *List of changes since Ivy 2.4.0:* - FIX: Local conflict manager didn't handle deeper conflicts in transitive dependencies (jira:IVY-1404[]) -- FIX: Made the maven 'test' configuration public so we can use the test-jar as dependency (jira:IVY-1444[]) +- FIX: Made the Maven 'test' configuration public so we can use the test-jar as dependency (jira:IVY-1444[]) - FIX: NullPointerException in dependencytree with no dependencies (jira:IVY-1539[]) - FIX: checkIfChanged is not settable attribute for checkdepsupdate ant task (jira:IVY-1549[]) - FIX: ArrayIndexOutOfBoundsException when using a p2 repository for dependencies (jira:IVY-1504[]) @@ -74,11 +74,11 @@ For details about the following changes, check our JIRA install at link:https:// - IMPROVEMENT: Throw an IllegalStateException when retrieving the resolutionCacheRoot on the DefaultResolutionCacheManager if the basedir (or IvySettings) is not set (jira:IVY-1482[]) - IMPROVEMENT: Optimization: limit the revision numbers scanned if revision prefix is specified (Thanks to Ernestas Vaiciukevičius) - IMPROVEMENT: Update bouncycastle to 1.52 (jira:IVY-1521[]) (Thanks to Michal Srb) -- IMPROVEMENT: `symlinkmass` option of retrieve task has been deprecated in this release and will no longer be supported since, starting this version of Ivy, Ivy uses Java standard API(s) for symlink management and as such doesn't spawn a process to execute symlink creation shell commands, like it used to do eariler. The `symlinkmass` option was previously there to launch just one single process instead of multiple processes for symlink creation. Now with the usage of the Java standard API(s), this option no longer is relevant. +- IMPROVEMENT: `symlinkmass` option of retrieve task has been deprecated in this release and will no longer be supported since, starting this version of Ivy, Ivy uses Java standard API(s) for symlink management and as such doesn't spawn a process to execute symlink creation shell commands, like it used to do earlier. The `symlinkmass` option was previously there to launch just one single process instead of multiple processes for symlink creation. Now with the usage of the Java standard API(s), this option no longer is relevant. - IMPROVEMENT: Ivy command line now supports passing `overwriteMode` option to `retrieve` task (jira:IVY-1447[]) -- NEW: Lets ssh-based resolvers use an ~/.ssh/config file to find username/hostname/keyfile options (Thanks to Colin Stanfill) +- NEW: Lets SSH-based resolvers use an ~/.ssh/config file to find username/hostname/keyfile options (Thanks to Colin Stanfill) - NEW: Add ivy.maven.lookup.sources and ivy.maven.lookup.javadoc variables to control the lookup of the additional artifacts. Defaults to true, for backward compatibility (jira:IVY-1529[]) - NEW: Add (conditional) support for SHA-256 SHA-512 and SHA-384 checksum algorithms (jira:IVY-1554[]) (Thanks to Jaikiran Pai) http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/chain.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/chain.adoc b/asciidoc/resolver/chain.adoc index b3fb992..a228ccb 100644 --- a/asciidoc/resolver/chain.adoc +++ b/asciidoc/resolver/chain.adoc @@ -67,7 +67,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute ---- -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. +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. ''' @@ -85,7 +85,7 @@ Both a filesystem and ivyrep will be used to look for ivy files. If a dynamic re ---- -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. +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. ''' @@ -103,4 +103,4 @@ Same as before, except that if a revision is found in the filesystem then ivyrep ---- -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. +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. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/dual.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/dual.adoc b/asciidoc/resolver/dual.adoc index 891d00c..4329ef3 100644 --- a/asciidoc/resolver/dual.adoc +++ b/asciidoc/resolver/dual.adoc @@ -23,11 +23,11 @@ |======= |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 +|Handle publish|delegates to Ivy sub resolver if artifact to publish is of "ivy" type, to artifact sub resolver otherwise |======= -This resolver delegates its job to one resolver for ivy files and another for artifacts. +This resolver delegates its job to one resolver for Ivy files and another for artifacts. == Attributes @@ -41,5 +41,5 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|any resolver|two resolvers, the first being the ivy resolver, the second the artifact resolver|2 +|any resolver|two resolvers, the first being the Ivy resolver, the second the artifact resolver|2 |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/filesystem.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/filesystem.adoc b/asciidoc/resolver/filesystem.adoc index aaca9a0..f1ea725 100644 --- a/asciidoc/resolver/filesystem.adoc +++ b/asciidoc/resolver/filesystem.adoc @@ -27,9 +27,9 @@ |======= -This resolver uses the file system to resolve ivy files and artifacts. An advantage of this resolver is that it usually provides very good performance. Moreover, it is easy to setup using basic OS file sharing mechanisms. +This resolver uses the file system to resolve Ivy files and artifacts. An advantage of this resolver is that it usually provides very good performance. Moreover, it is easy to setup using basic OS file sharing mechanisms. -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. These patterns must be absolute paths (*__since 2.0__*). You can indicate a list of patterns which will be checked one after the other. +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. These patterns must be absolute paths (*__since 2.0__*). You can indicate a list of patterns which will be checked one after the other. *__since 1.3__* Using the `m2compatible` attribute, this resolver will convert dots found in organisation into slashes like Maven 2 does for groupId. For instance, it will transform the organisation from `com.company` into `com/company` when replacing the token `[organisation]` in your pattern. @@ -45,9 +45,9 @@ In this case the resolver starts by publishing the module according to the patte Atomic publish is currently limited in several ways: - * you need to use a pattern for both the artifact and the ivy files which uses the revision as a directory. For instance `${repository.dir}/[module]/[revision]/[artifact].[ext]` works, `${repository.dir}/[module]/[artifact]-[revision].[ext]` doesn't + + * you need to use a pattern for both the artifact and the Ivy files which uses the revision as a directory. For instance, `${repository.dir}/[module]/[revision]/[artifact].[ext]` works, `${repository.dir}/[module]/[artifact]-[revision].[ext]` doesn't + - * both the artifact and ivy pattern should have the same prefix until the `[revision]` token. + + * both the artifact and Ivy pattern should have the same prefix until the `[revision]` token. + * overwrite during publish is not supported + @@ -85,6 +85,6 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|ivy|defines a pattern for ivy files, using the pattern attribute|0..n +|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 |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/ibiblio.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/ibiblio.adoc b/asciidoc/resolver/ibiblio.adoc index 9a0aea4..2ed7ea8 100644 --- a/asciidoc/resolver/ibiblio.adoc +++ b/asciidoc/resolver/ibiblio.adoc @@ -29,9 +29,9 @@ This resolver usually uses ibiblio to find artifacts. -*__since 1.3__* Using the `m2compatible` attribute, you can benefit from Maven 2 repository compatibility (convert dots in organisation into slashes, search for poms, use transitive dependencies of poms). This setting also affects the default place where the resolver looks for its artifacts to point to the Maven 2 repository. So setting this attribute to `true` is sufficient to use Maven 2 ibiblio repository. +*__since 1.3__* Using the `m2compatible` attribute, you can benefit from Maven 2 repository compatibility (convert dots in organisation into slashes, search for POMs, use transitive dependencies of POMs). This setting also affects the default place where the resolver looks for its artifacts to point to the Maven 2 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 a url resolver configured like this: +*__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 a URL resolver configured like this: [source, xml] ---- @@ -42,7 +42,7 @@ This resolver usually uses ibiblio to find artifacts. ---- -*__since 2.0__* When used in `m2compatible` mode with the default pattern, this resolver uses `maven-metadata.xml` files (if present) to list the revisions available on the repository. This is especially useful when using a maven specific proxy, which does not serve directory listing. This can be disabled by using the `useMavenMetadata` flag. +*__since 2.0__* When used in `m2compatible` mode with the default pattern, this resolver uses `maven-metadata.xml` files (if present) to list the revisions available on the repository. This is especially useful when using a Maven specific proxy, which does not serve directory listing. This can be disabled by using the `useMavenMetadata` flag. *Limitation*: in `m2compatible` mode, this resolver is not able list available organizations. It means some features like link:../use/repreport.html[repreport] are not available. @@ -54,10 +54,10 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header",cols="15%,50%,35%"] |======= |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} +|root|the root of the artifact repository.|No, defaults to ${ivy.ibiblio.default.artifact.root} +|pattern|a pattern describing the layout of the artifact repository.|No, defaults to ${ivy.ibiblio.default.artifact.pattern} |m2compatible|True if this resolver should be Maven 2 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 +|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 |useMavenMetadata|True if this resolver should use maven-metadata.xml files to list available revisions, false to use directory listing *__since 2.0__*|No, defaults to true |======= @@ -73,7 +73,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute ---- -Defines a resolver called `maven2` using the Maven 2 public repository to find module metadata (using Maven 2 poms) and artifacts. +Defines a resolver called `maven2` using the Maven 2 public repository to find module metadata (using Maven 2 POMs) and artifacts. ''' @@ -86,4 +86,4 @@ Defines a resolver called `maven2` using the Maven 2 public repository to find m ---- -Same as above, but doesn't use poms, only artifacts. +Same as above, but doesn't use POMs, only artifacts. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/ivyrep.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/ivyrep.adoc b/asciidoc/resolver/ivyrep.adoc index 91ca9c2..6250f8a 100644 --- a/asciidoc/resolver/ivyrep.adoc +++ b/asciidoc/resolver/ivyrep.adoc @@ -45,8 +45,8 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|ivyroot|the root of the ivy repository.|Yes, but may be provided through ${ivy.ivyrep.default.ivy.root} *__since 2.0__* -|ivypattern|a pattern describing the layout of the ivy repository.|No, defaults to ${ivy.ivyrep.default.ivy.pattern} +|ivyroot|the root of the Ivy repository.|Yes, but may be provided through ${ivy.ivyrep.default.ivy.root} *__since 2.0__* +|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} |======= @@ -62,4 +62,4 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute ---- -Looks for ivy files on and ivyrep like web site located at `http://ivyrep.mycompany.com`. +Looks for Ivy files in an ivyrep like web site located at `http://ivyrep.mycompany.com`. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/jar.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/jar.adoc b/asciidoc/resolver/jar.adoc index 9f2ecb7..581e36c 100644 --- a/asciidoc/resolver/jar.adoc +++ b/asciidoc/resolver/jar.adoc @@ -29,11 +29,11 @@ *__since 2.3__* -This resolver uses a specified jar resolve ivy files and artifacts. +This resolver uses a specified jar resolve Ivy files and artifacts. This kind of resolver helps the packaging of an entire repository. Since the entire "repository" jar is expected to be local at some point, the size of a such repository should be considered to be not too large if it is expected to be remote; hence the artifacts in a such repo should be little in size. -The configuration of such a resolver is done via specifying the location of the jar, and through ivy and artifact patterns, indicating where ivy files and artifacts can be found in the jar. You can indicate a list of patterns which will be checked one after the other. Note that the patterns *MUST NOT* start with a slash. +The configuration of such a resolver is done via specifying the location of the jar, and through Ivy and artifact patterns, indicating where Ivy files and artifacts can be found in the jar. You can indicate a list of patterns which will be checked one after the other. Note that the patterns *MUST NOT* start with a slash. == Attributes @@ -54,7 +54,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|ivy|defines a pattern for ivy files, using the pattern attribute|0..n +|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 |======= @@ -91,4 +91,4 @@ A simple local jar repository. ---- -A remote jar repository with multiple ivy and artifact patterns, patterns pointing in some sub directories in the jar. +A remote jar repository with multiple Ivy and artifact patterns, patterns pointing in some sub directories in the jar. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/mirrored.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/mirrored.adoc b/asciidoc/resolver/mirrored.adoc index 858847a..8be2d96 100644 --- a/asciidoc/resolver/mirrored.adoc +++ b/asciidoc/resolver/mirrored.adoc @@ -22,14 +22,14 @@ [] |======= |Tag|mirroredurl -|Handle latest|yes with http urls (and apache server) and with file urls, no with other urls +|Handle latest|yes with HTTP URLs (and Apache server) and with file URLs, no with other URLs |Handle publish|no |======= *__since 2.3__* -This resolver can resolve dependencies against several mirrors of the same repository. From a list of mirror urls, it will iteratively try to resolve the dependencies against each one. +This resolver can resolve dependencies against several mirrors of the same repository. From a list of mirror URLs, it will iteratively try to resolve the dependencies against each one. == Attributes @@ -40,7 +40,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |======= |Attribute|Description|Required |m2compatible|True if this resolver should be Maven 2 compatible, false otherwise|No, defaults to false -|mirrorListUrl|The url where to retrieve the list of mirror urls.|Yes +|mirrorListUrl|The URL where to retrieve the list of mirror URLs.|Yes |======= @@ -50,7 +50,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|ivy|defines a pattern for ivy files, using the pattern attribute|0..n +|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 |======= @@ -86,7 +86,7 @@ It will resolve first on the `repo1` and if failing it will fall back on `repo2` ''' -The mirror list can be retrieved from a geo-location aware url: +The mirror list can be retrieved from a geo-location aware URL: [source, xml] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/obr.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/obr.adoc b/asciidoc/resolver/obr.adoc index 4f4d2a0..d33bbb3 100644 --- a/asciidoc/resolver/obr.adoc +++ b/asciidoc/resolver/obr.adoc @@ -29,7 +29,7 @@ *__since 2.3__* -This resolver is one of the resolver which supports link:../osgi.html[OSGi™] dependencies. As part of the OSGi specification resides the OBR (OSGi Bundle Repository). The OBR defines the aggregation of the OSGi metadata of every bundle included in an repository. So contrary to the other resolvers, this resolver needs to get the descriptor of the repository (an obr.xml) before starting to resolve modules. +This resolver is one of the resolver which supports link:../osgi.html[OSGi™] dependencies. A part of the OSGi specification defines OBR (OSGi Bundle Repository). OBR aggregates the OSGi metadata of every bundle included in a repository. So contrary to the other resolvers, this resolver needs to get the descriptor of the repository (an obr.xml) before starting to resolve modules. == Attributes @@ -47,7 +47,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |======= -The requirement strategy is defining how the resolver should behave in front of several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur: +The requirement strategy is defining how the resolver should behave when facing several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur: * if the requirement strategy is `first`, among the bundles satisfying the requirement, it will choose the first one. A warning will be logged about the choice Ivy has to arbitrarily do. + http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/osgiagg.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/osgiagg.adoc b/asciidoc/resolver/osgiagg.adoc index 5c6275b..a2b1ec7 100644 --- a/asciidoc/resolver/osgiagg.adoc +++ b/asciidoc/resolver/osgiagg.adoc @@ -29,9 +29,9 @@ *__since 2.4__* -This resolver is one of the resolver which supports link:../osgi.html[OSGi™] dependencies. +This resolver is one of the resolvers which support link:../osgi.html[OSGi™] dependencies. -This resolvers is like a classic link:../resolver/chain.html[chain] resolver, but which better support OSGi metadata. +This resolvers is like a classic link:../resolver/chain.html[chain] resolver, but with better support for OSGi metadata. == Attributes http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/packager.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/packager.adoc b/asciidoc/resolver/packager.adoc index 87568a1..abef42b 100644 --- a/asciidoc/resolver/packager.adoc +++ b/asciidoc/resolver/packager.adoc @@ -22,14 +22,14 @@ [] |======= |Tag|packager -|Handle latest|yes with http urls (and apache server) and with file urls, no with other urls +|Handle latest|yes with HTTP URLs (and Apache server) and with file URLs, no with other URLs |Handle publish|no |======= *__Since 2.0__*. -This resolver accesses ivy files and "packaging instructions" from an online "packager" repository. "Packager" repositories contain no actual artifacts. To get the artifacts, the packaging instructions are downloaded from the repository and executed locally. These instructions specify additional resource(s) to download and how to create the artifacts from them, for example, by downloading a project's original distribution archive directly from their web site and extracting the desired artifacts. +This resolver accesses Ivy files and "packaging instructions" from an online "packager" repository. "Packager" repositories contain no actual artifacts. To get the artifacts, the packaging instructions are downloaded from the repository and executed locally. These instructions specify additional resource(s) to download and how to create the artifacts from them, for example, by downloading a project's original distribution archive directly from their web site and extracting the desired artifacts. Packager repositories allow the creation of Ivy repositories that require neither the participation of any of the modules' creators nor setting up a huge mirror site. @@ -37,13 +37,13 @@ Packager repositories allow the creation of Ivy repositories that require neithe The Packager resolver supports a "resource cache", where downloaded archives can be stored to avoid duplicate downloads. This cache is entirely separate from the link:../concept.html#cache[normal Ivy cache]: it is "private" to the Packager resolver, and it stores unmodified original software archives, not Ivy artifacts. See the `resourceCache` attribute below for details. -The packaging instructions are contained in "packager.xml" in a simple XML format. At resolve time this file gets converted into a "build.xml" file via XSLT and then executed using link:https://ant.apache.org/[Ant]. Therefore, Ant must be available as an executable on the platform. The ant task executes in a separate ant project and so is not affected by properties, etc. that may be set in any existing ant environment in which Ivy is running. However, Ivy will define a few properties for convenience; see the "Properties" listed below. +The packaging instructions are contained in "packager.xml" in a simple XML format. At resolve time this file gets converted into a "build.xml" file via XSLT and then executed using link:https://ant.apache.org/[Ant]. Therefore, Ant must be available as an executable on the platform. The Ant task executes in a separate Ant project and so is not affected by properties, etc. that may be set in any existing Ant environment in which Ivy is running. However, Ivy will define a few properties for convenience; see the "Properties" listed below. For security reasons, the XSLT transform ensures that a. all downloaded archives have verified SHA1 checksums (including cached resources); and - b. only a very limited set of ant tasks can be performed during the artifact "build" phase; currently these include move, copy, mkdir, zip, unzip, tar, and untar (this restriction may be overridden however; see below). + b. only a very limited set of Ant tasks can be performed during the artifact "build" phase; currently these include move, copy, mkdir, zip, unzip, tar, and untar (this restriction may be overridden however; see below). The Packager resolver is based on the link:url.html[URL resolver] and is configured similarly, except the artifact child tags specify where to find the packager.xml files, rather than the artifacts themselves. @@ -60,11 +60,11 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |buildRoot|Defines the root of the temporary build directory hierarchy|Yes |resourceCache|Directory where downloaded resources should be cached|No; defaults to none |resourceURL|Ivy pattern that specifies a base URL to use for downloading __all__ resources; overrides the URLs in the packaging instructions|No; defaults to none -|restricted|True if this resolver should only allow "safe" ant tasks in the packaging instructions. *Warning:* setting `restricted` to false creates a security problem due to ant tasks like delete, exec, etc. Do not use this setting when your configuration points to an untrusted repository.|No; defaults to true -|verbose|True to run ant with the -verbose flag|No; defaults to false -|quiet|True to run ant with the -quiet flag|No; defaults to false +|restricted|True if this resolver should only allow "safe" Ant tasks in the packaging instructions. *Warning:* setting `restricted` to false creates a security problem due to Ant tasks like delete, exec, etc. Do not use this setting when your configuration points to an untrusted repository.|No; defaults to true +|verbose|True to run Ant with the -verbose flag|No; defaults to false +|quiet|True to run Ant with the -quiet flag|No; defaults to false |validate|True if this resolver should validate (via XSD) the downloaded XML packaging instructions|No; defaults to true -|preserveBuildDirectories|True if this resolver should not delete the temporary build directories in which the ant tasks are executed (for debugging purposes)|No; defaults to false +|preserveBuildDirectories|True if this resolver should not delete the temporary build directories in which the Ant tasks are executed (for debugging purposes)|No; defaults to false |======= @@ -105,30 +105,13 @@ Configure a resourceURL in situations where you don't want to rely on (or wait f ---- Defines a packager resolver which points to the `http://ivyroundup.googlecode.com/` online repository. Builds will occur in a subdirectory of -[source] ----- -${user.home}/.ivy2/packager/build ----- - -downloaded resources will be cached in -[source] ----- -${user.home}/.ivy2/packager/cache ----- - -and the mirror site -[source] ----- -ftp://mirror.example.com/pub/resources/[organisation]/[module]/ ----- - -will be tried first for all resources. +`${user.home}/.ivy2/packager/build`, downloaded resources will be cached in `${user.home}/.ivy2/packager/cache` and the mirror site `ftp://mirror.example.com/pub/resources/[organisation]/[module]/` will be tried first for all resources. == Packaging Instructions -The goal of the packaging instructions is to download the required archives, extract the artifacts, and put the artifacts into a subdirectory. Each artifact should be written to `artifacts/[type]s/[artifact].[ext]` when the ant build completes. +The goal of the packaging instructions is to download the required archives, extract the artifacts, and put the artifacts into a subdirectory. Each artifact should be written to `artifacts/[type]s/[artifact].[ext]` when the Ant build completes. Below is an example of packaging instructions for link:http://testng.org/[TestNG]: @@ -183,15 +166,15 @@ Of course, packaging instructions must produce artifacts consistent with those l == Build-time properties -This resolver ensures following ant properties are defined when it executes the ant build task. +This resolver ensures following Ant properties are defined when it executes the Ant build task. [options="header",cols="15%,50%"] |======= |Property|Description -|ivy.packager.organisation|Organization of the ivy module whose artifacts are being built -|ivy.packager.module|Module of the ivy module whose artifacts are being built -|ivy.packager.revision|Revision of the ivy module whose artifacts are being built -|ivy.packager.branch|Branch of the ivy module whose artifacts are being built +|ivy.packager.organisation|Organization of the Ivy module whose artifacts are being built +|ivy.packager.module|Module of the Ivy module whose artifacts are being built +|ivy.packager.revision|Revision of the Ivy module whose artifacts are being built +|ivy.packager.branch|Branch of the Ivy module whose artifacts are being built |ivy.packager.resourceCache|The configured `resourceCache` if any; otherwise not defined |ivy.packager.resourceURL|The resolved `resourceURL` pattern if any; otherwise not defined |======= @@ -205,20 +188,20 @@ The packager.xml document element can contain the following child tags. [options="header"] |======= |Element|Description|Cardinality -|property|Set an ant property|0..n +|property|Set an Ant property|0..n |resource|Define a resource to download and (optionally) unpack|0..n |m2resource|Define a Maven 2 resource to download and (optionally) unpack|0..n -|build|Specify ant tasks that ultimately result in each artifact being placed into artifacts/[type]s/[artifact].[ext]|0..1 +|build|Specify Ant tasks that ultimately result in each artifact being placed into artifacts/[type]s/[artifact].[ext]|0..1 |======= -Which ant tasks are allowed within the build tag is controlled by the `restricted` configuration attribute. When true (the default), only the following ant tasks are allowed: copy, jar, mkdir, move, tar, unjar, untar, unwar, unzip, war, and zip. When false, all ant tasks are allowed. +Which Ant tasks are allowed within the build tag is controlled by the `restricted` configuration attribute. When true (the default), only the following Ant tasks are allowed: copy, jar, mkdir, move, tar, unjar, untar, unwar, unzip, war, and zip. When false, all Ant tasks are allowed. -*Warning:* setting `restricted` to false creates a security problem due to ant tasks like delete, exec, etc. Do not use this setting when your configuration points to an untrusted repository. +*Warning:* setting `restricted` to false creates a security problem due to Ant tasks like delete, exec, etc. Do not use this setting when your configuration points to an untrusted repository. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/sftp.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/sftp.adoc b/asciidoc/resolver/sftp.adoc index 9012b7c..b90c3f3 100644 --- a/asciidoc/resolver/sftp.adoc +++ b/asciidoc/resolver/sftp.adoc @@ -28,23 +28,23 @@ *__since 1.4__* -This resolver can be used when your ivy repository is located on a server accessible via sftp. The secured nature of sftp and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. +This resolver can be used when your Ivy repository is located on a server accessible via SFTP. The secured nature of SFTP and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. -If your server supports ssh but not sftp, there is also an link:../resolver/ssh.html[ssh resolver]. +If your server supports SSH but not SFTP, there is also an link:../resolver/ssh.html[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. +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, or via an OpenSSH-style config file specified by `sshConfig`. -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:geh...@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. +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:geh...@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 preferable. +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 preferable. -Internally this resolver relies on link:http://www.jcraft.com/jsch/[jsch] as ssh client, which is a popular java ssh client, used for example in Eclipse. +Internally this resolver relies on link:http://www.jcraft.com/jsch/[jsch] as SSH client, which is a popular Java SSH client, used for example in Eclipse. == Attributes @@ -60,8 +60,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |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 -|sshConfig|Path to an OpenSSH-style config file containing additional - configuration|No +|sshConfig|Path to an OpenSSH-style config file containing additional configuration|No |======= @@ -71,7 +70,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|ivy|defines a pattern for ivy files, using the pattern attribute|0..n +|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 |======= @@ -105,7 +104,7 @@ Will connect to myhost.com using myuser and prompt for the password. ---- -Will connect to myhost.com using user and password provided with ivy variables. +Will connect to myhost.com using user and password provided with Ivy variables. ''' @@ -120,7 +119,7 @@ Will connect to myhost.com using user and password provided with ivy variables. ---- -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. +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. ''' @@ -135,7 +134,7 @@ Will connect to yourserver.com on port 8022 with user 'user' and password 'gehei ---- -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. +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. [source, xml] http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/ssh.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/ssh.adoc b/asciidoc/resolver/ssh.adoc index 8c65e09..02c7ee8 100644 --- a/asciidoc/resolver/ssh.adoc +++ b/asciidoc/resolver/ssh.adoc @@ -28,11 +28,11 @@ *__since 1.4__* -This resolver can be used when your ivy repository is located on a server accessible via ssh. The secured nature of ssh and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. +This resolver can be used when your Ivy repository is located on a server accessible via SSH. The secured nature of SSH and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. -If your server supports sftp, you can consider using the link:../resolver/sftp.html[sftp resolver]. +If your server supports SFTP, you can consider using the link:../resolver/sftp.html[SFTP resolver]. -Internally this resolver shares most of its behaviour with the link:../resolver/sftp.html[sftp resolver], so refer to its documentation for details. +Internally this resolver shares most of its behaviour with the link:../resolver/sftp.html[SFTP resolver], so refer to its documentation for details. == Attributes @@ -47,8 +47,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |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 -|sshConfig|Path to an OpenSSH-style config file containing additional - configuration|No +|sshConfig|Path to an OpenSSH-style config file containing additional configuration|No |publishPermissions|A four digit string (e.g., 0644, see "man chmod", "man open") specifying the permissions of the published files. *__(since 2.0)__* |No, defaults to scp standard behaviour |======= @@ -60,7 +59,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute [options="header"] |======= |Element|Description|Cardinality -|ivy|defines a pattern for ivy files, using the pattern attribute|0..n +|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 |======= @@ -94,7 +93,7 @@ Will connect to myhost.com using myuser and prompt for the password. ---- -Will connect to yourserver.com on port 8022 with user geheim and use `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. +Will connect to yourserver.com on port 8022 with user geheim and use `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. [source, xml] http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/614bf1ad/asciidoc/resolver/updatesite.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/resolver/updatesite.adoc b/asciidoc/resolver/updatesite.adoc index d8c977e..aa5182e 100644 --- a/asciidoc/resolver/updatesite.adoc +++ b/asciidoc/resolver/updatesite.adoc @@ -29,10 +29,10 @@ *__since 2.3__* -This resolver is one of the resolver which supports link:../osgi.html[OSGi™] dependencies. +This resolver is one of the resolvers which support link:../osgi.html[OSGi™] dependencies. It resolves modules (OSGi bundles) which are hosted in an Eclipse™ update site. -This resolver supports old style Eclipse updatesite, based on simply a site.xml. It also supports Eclipse P2 repositories. +This resolver supports old style Eclipse updatesite, based on a single file, site.xml. It also supports Eclipse P2 repositories. == Attributes @@ -49,7 +49,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute |======= -The requirement strategy is defining how the resolver should behave in front of several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur: +The requirement strategy is defining how the resolver should behave when facing several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur: * if the requirement strategy is `first`, among the bundles satisfying the requirement, it will choose the first one. A warning will be logged about the choice Ivy has to arbitrarily do. +
