http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/buildnumber.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/buildnumber.adoc b/asciidoc/use/buildnumber.adoc index 6560f9e..1153a47 100644 --- a/asciidoc/use/buildnumber.adoc +++ b/asciidoc/use/buildnumber.adoc @@ -20,7 +20,7 @@ *__since 1.4__* The `buildnumber` task is similar to the Ant `buildnumber` task, except that it uses Ivy repository to find what is the latest version and calculate a new one for you. -When called it sets four properties according to what has been found. These properties are: +When called, it sets four properties according to what has been found. These properties are: * `ivy.revision`: the last revision found in the repository * `ivy.new.revision`: the new revision calculated from the last one (see below) @@ -33,7 +33,7 @@ Build numbers are always numbers (composed of digit characters only). `ivy.build.number` can be not set if no revision was found or if no number was found in it. -`ivy.new.build.number` can be not set if the default new revision to use when no revision is found do not contain any number. +`ivy.new.build.number` can be not set if the default new revision to use when no revision is found does not contain some number. The new revision is calculated using a somewhat complex to explain but very easy to use algorithm, depending on which latest version you asked. @@ -50,7 +50,7 @@ Examples (suppose the latest version of the module is 1.3.1): ||1.3.1|1.3.2|1|2 |======= -Note that when asking for revision 1, you can get a revision 10.0. To avoid that you can use 1. as revision asked, but in this case ivy won't find revision 1 if its the latest one, and it will thus give 1.0 as new revision. The solution to this problem is to use versions with always the same number of parts (for instance 1.0.0 instead of 1). +Note that when asking for revision 1, you can get a revision 10.0. To avoid that you can use 1. as revision asked, but in this case Ivy won't find revision 1 if its the latest one, and it will thus give 1.0 as new revision. The solution to this problem is to use versions with always the same number of parts (for instance, 1.0.0 instead of 1). == Attributes @@ -65,13 +65,13 @@ Note that when asking for revision 1, you can get a revision 10.0. To avoid that |defaultBuildNumber|the default build number to use for the first revision|No, defaults to 0 |revSep|the revision separator to use when no matching revision is found, to separate the revision prefix from the build number|No, defaults to `.` |prefix|the prefix to use for the property names set (will be `__prefix__.revision, __prefix__.new.revision, ...)|No, defaults to `ivy` -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*.|No, `ivy.instance` is taken by default. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*.|No, `ivy.instance` is taken by default. |resolver|the name of the resolver to use for build number calculation *__(since 2.1)__*|No, all available resolvers will be used by default. |======= == Examples -Here is how it can be used (suppose 1.3.1 is the latest version of ivy in the repository): +Here is how it can be used (suppose 1.3.1 is the latest version of Ivy in the repository): [source,xml] ----
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/buildobr.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/buildobr.adoc b/asciidoc/use/buildobr.adoc index cdc0fd5..ac39557 100644 --- a/asciidoc/use/buildobr.adoc +++ b/asciidoc/use/buildobr.adoc @@ -19,14 +19,14 @@ *__since 2.3__* From a set of jar artifacts, this task generates an OBR (OSGi Bundle Repository) descriptor. It could be then used by the link:../resolver/obr.html[obr resolver]. -The set of jars which will be described by the OBR can be defined in 4 exclusive ways: +The set of jars which will be described by OBR can be defined in 4 mutually exclusive ways: * via an Ivy resolver: every jar listed by the resolver will be taken into account * by defining a root directory: every jar found recursively in that folder will be taken into account * via the name of an Ivy cache: every artifact contained in the cache will be taken into account -* *__since 2.4__* via a resolve: this task is a link:../use/postresolvetask.html[post resolve task] (with all the behaviour and attributes common to all post resolve tasks), thus ever artifact which has been resolved will be taken into account; it is especially useful for building a link:../osgi/target-platform.html[target platform] +* *__since 2.4__* via a resolve: this task is a link:../use/postresolvetask.html[post resolve task] (with all the behaviour and attributes common to all post resolve tasks), thus every artifact which has been resolved will be taken into account; it is especially useful for building a link:../osgi/target-platform.html[target platform] -NB: among every listed files or artifacts, only the actually OSGi bundles will be described by the OBR descriptor; the other files are ignored. +NB: among every listed file or artifact, only the actually OSGi bundles will be described by the OBR descriptor; the other files are ignored. == Attributes @@ -38,11 +38,11 @@ NB: among every listed files or artifacts, only the actually OSGi bundles will b |out|the location of the descriptor file to generate|Yes |resolverName|the name of the resolver from which the jars should be to gathered|No |cacheName|the name of the cache from which the jars should be to gathered|No -|baseDir|the folder into which the jars should be gather recursively|No -|sourceType|if used as a post resolve task, `sourceType` define the type of artifacts which should be considered as source artifacts|No. Defaults to `source,sources,src` -|encoding|The encoding of the resulting xml file|No. Defaults to `UTF-8` -|indent|Specify if the xml result file should be indented|No. Defaults to `true` -|quiet|Log as debug rather than warning the rejected jars as they are ill-formed|No. Defaults to `false` +|baseDir|the folder into which the jars should be gathered recursively|No +|sourceType|if used as a post resolve task, `sourceType` defines the type of artifacts which should be considered as source artifacts|No. Defaults to `source,sources,src` +|encoding|The encoding of the resulting XML file|No. Defaults to `UTF-8` +|indent|Specify if the XML result file should be indented|No. Defaults to `true` +|quiet|Log the rejected jars that are ill-formed as debug rather than warning|No. Defaults to `false` |======= == Examples @@ -62,7 +62,7 @@ Builds an indented OBR descriptor from an Eclipse install, with their path relat <ivy:buildobr resolverName="my-file-resolver" out="${basedir}/target/repo-eclipse.xml"/> ---- -Configure an Ivy settings and builds an OBR descriptor from jars resolved by the defined resolver. +Configures Ivy settings and builds an OBR descriptor from jars resolved by the defined resolver. ''' @@ -72,7 +72,7 @@ Configure an Ivy settings and builds an OBR descriptor from jars resolved by the <ivy:buildobr cacheName="my-cache" out="${basedir}/target/repo-eclipse.xml"/> ---- -Configure an Ivy settings and builds an OBR descriptor from jars contained in the defined cache. +Configures Ivy settings and builds an OBR descriptor from jars contained in the defined cache. ''' @@ -83,4 +83,4 @@ Configure an Ivy settings and builds an OBR descriptor from jars contained in th <ivy:buildobr out="${basedir}/target-platform-obr.xml"/> ---- -Launch a resolve and then build an obr.xml describing the resolved artifacts. +Launches a resolve and then builds an obr.xml describing the resolved artifacts. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/cachefileset.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cachefileset.adoc b/asciidoc/use/cachefileset.adoc index 0e5b0af..654d717 100644 --- a/asciidoc/use/cachefileset.adoc +++ b/asciidoc/use/cachefileset.adoc @@ -17,20 +17,20 @@ under the License. //// -Constructs an Ant `fileset consisting` of artifacts in Ivy's cache for a configuration (*__since 1.2__*). +Constructs an Ant `fileset` consisting of artifacts in Ivy's cache for a configuration (*__since 1.2__*). This is a link:../use/postresolvetask.html[post resolve task], with all the behaviour and attributes common to all post resolve tasks. Note that this task -does not rely on retrieve, because built fileset is made of artifacts directly in Ivy's cache. +does not rely on retrieve, because the built fileset is made of artifacts directly in Ivy's cache. -Please prefer the use of retrieve + standard ant path creation, which make your build +Please prefer the use of retrieve + standard Ant path creation, which make your build more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). -Built `fileset` is registered in Ant with a given id, and can thus be used like any other Ant `fileset` using +Built `fileset` is registered in Ant project with a given id, and can thus be used like any other Ant `fileset` using `refid`. == Limitation -A `fileset`, in Ant, requires a base directory from within which the files are included/excluded. The `cachefileset` task, in Ivy, internally tries to determine a common base directory across all the resolved artifacts' files that have been downloaded in the Ivy repository cache(s). Given that Ivy can be configured to consist multiple repository caches and each one can potentially be on a different filesystem root, there are times, when `cachefileset` cannot determine a common base directory for these resolved artifacts. The `cachefileset` throws an exception in such cases. +A `fileset`, in Ant project, requires a base directory from within which the files are included/excluded. The `cachefileset` task, in Ivy, internally tries to determine a common base directory across all the resolved artifact files that have been downloaded in the Ivy repository cache(s). Given that Ivy can be configured to use multiple repository caches and each one can potentially be on a different filesystem root, there are times, when `cachefileset` cannot determine a common base directory for these resolved artifacts. The `cachefileset` throws an exception in such cases. == Alternative task @@ -44,5 +44,5 @@ If `cachefileset` doesn't fit the need of your use case (maybe due to the limita |setid|the id to reference the built fileset|Yes |conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called |type|comma separated list of artifact types to accept in the path, `*` for all|No. Defaults to `*` -|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default. +|settingsRef|*__(since 2.0)__* A reference to Ivy settings that must be used by this task|No, `ivy.instance` is taken by default. |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/cachepath.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cachepath.adoc b/asciidoc/use/cachepath.adoc index 0cc66ee..6435195 100644 --- a/asciidoc/use/cachepath.adoc +++ b/asciidoc/use/cachepath.adoc @@ -23,7 +23,7 @@ This is a link:../use/postresolvetask.html[post resolve task], with all the beha If you want to make your build more independent from Ivy, you could consider using the link:../use/retrieve.html[retrieve task]. Once the artifacts are properly retrieved, you can use standard Ant path creation which makes Ivy not necessary any more. -Built path is registered in ant with a given id, and can thus be used like any other Ant path using `refid`. +Built path is registered in the Ant project with a given id, and can thus be used like any other Ant path using `refid`. == Attributes @@ -33,7 +33,7 @@ Built path is registered in ant with a given id, and can thus be used like any o |pathid|the id to reference the built path|Yes |conf|a comma separated list of the configurations to put in the created path|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called |type|comma separated list of artifact types to accept in the path, `$$*$$` for all (*__since 1.2__*)|No. Defaults to `*` -|settingsRef|*__(since 2.0)__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default. +|settingsRef|*__(since 2.0)__* A reference to Ivy settings that must be used by this task|No, `ivy.instance` is taken by default. |======= == Examples @@ -62,4 +62,4 @@ Same as before but will use the original location for local artifacts, and the c <taskdef resource="emma_ant.properties" classpathref="emma.classpath"/> ---- -Resolves the Emma module in version 2.0.4217, constructs an Ant path with the corresponding artifacts, and then define the Emma tasks using this path. +Resolves the Emma module in version 2.0.4217, constructs an Ant path with the corresponding artifacts, and then defines the Emma tasks using this path. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/checkdepsupdate.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/checkdepsupdate.adoc b/asciidoc/use/checkdepsupdate.adoc index bb7bafb..24112c0 100644 --- a/asciidoc/use/checkdepsupdate.adoc +++ b/asciidoc/use/checkdepsupdate.adoc @@ -21,7 +21,7 @@ Display dependency updates on the console. This task can also show transitive de This is a link:../use/postresolvetask.html[post resolve task], with all the behaviour and attributes common to all post resolve tasks. -Please prefer the use of retrieve + standard ant path creation, which make your build more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). +Please prefer the use of retrieve + standard Ant path creation, which make your build more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). == Attributes @@ -30,7 +30,7 @@ Please prefer the use of retrieve + standard ant path creation, which make your |Attribute|Description|Required |revisionToCheck|target revision to check|No. Defaults to `latest.integration` |download|specify if artifact should be downloaded when new updates are found|No. Defaults to `false` -|checkIfChanged|When set to `true`, the resolve will compare the result with the last resolution done on this module, with those configurations in order to define the property ivy.deps.changed. Put it to false may provides slightly better performance.|No, default to `false` +|checkIfChanged|When set to `true`, the resolve will compare the result with the last resolution done on this module, with those configurations in order to define the property `ivy.deps.changed`. Put it to false may provides slightly better performance.|No, default to `false` |showTransitive|set to `true` if you want to see potential updates on transitive dependencies|No. Defaults to `false` |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/cleancache.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cleancache.adoc b/asciidoc/use/cleancache.adoc index 473ca9a..098ed17 100644 --- a/asciidoc/use/cleancache.adoc +++ b/asciidoc/use/cleancache.adoc @@ -27,7 +27,7 @@ This task is roughly equivalent to: <delete dir="${ivy.cache.dir}"/> ---- -Using the regular Ant delete task is more flexible, since it allows to specify the files to delete. But it requires an Ivy settings to be loaded, and settings scoping is possible only by using suffixed ant property for the cache directory. +Using the regular Ant delete task is more flexible, since it allows to specify the files to delete. But it requires Ivy settings to be loaded, and settings scoping is possible only by using a suffixed Ant property for the cache directory. This task loads the Ivy settings as any other post settings task, and allows easy scoping with the attribute `settingsRef`. @@ -36,7 +36,7 @@ This task loads the Ivy settings as any other post settings task, and allows eas [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|settingsRef|A reference to the ivy settings that must be used by this task|No. Defaults to `ivy.instance`. +|settingsRef|A reference to Ivy settings that must be used by this task|No. Defaults to `ivy.instance`. |======= == Examples http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/configure.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/configure.adoc b/asciidoc/use/configure.adoc index cdcbeb0..1c61b0a 100644 --- a/asciidoc/use/configure.adoc +++ b/asciidoc/use/configure.adoc @@ -17,13 +17,13 @@ under the License. //// -The `configure` task is used to configure ivy with an xml settings file. +The `configure` task is used to configure Ivy with an settings XML file. See link:../settings.html[Settings Files] for details about the settings file itself. *__since 2.0__* The file loaded used to be called __configuration__ file in versions prior to 2.0. The name __settings__ and the use of the `ivy.settings.file` is new to 2.0. -*__since 2.0__* It is also possible to configure Ivy with the link:../use/settings.html[settings] declaration. The difference with this task is that when using the settings declaration, the configuration of Ivy will be done when the settings are first needed (for instance when you do a resolve), while the configure task will perform a configuration of Ivy instantly, which makes it easier to see the problem if something goes wrong. +*__since 2.0__* It is also possible to configure Ivy with the link:../use/settings.html[settings] declaration. The difference with this task is that when using the settings declaration, the configuration of Ivy will be done when the settings are first needed (for instance, when you do a resolve), while the configure task will perform a configuration of Ivy instantly, which makes it easier to see the problem if something goes wrong. == Attributes @@ -32,8 +32,8 @@ See link:../settings.html[Settings Files] for details about the settings file it |Attribute|Description|Required |settingsId|The settings id usable in the `settingsRef` attributes of the Ivy task that needs a setting.|No, defaults to `ivy.instance` |file|path to the settings file to use -.2+|No. If a file is provided, url is ignored. If none are provided, then it attempts to find a file at `${ivy.settings.file}`, and if this file does not exist, it uses `${ivy.settings.url}` *__(since 2.3)__* or a link:../samples/ivysettings-default.xml[default settings file] -|url|url of the settings file to use +.2+|No. If a file is provided, URL is ignored. If none are provided, then it attempts to find a file at `${ivy.settings.file}`, and if this file does not exist, it uses `${ivy.settings.url}` *__(since 2.3)__* or a link:../samples/ivysettings-default.xml[default settings file] +|url|URL of the settings file to use |override|Specify what to do when another settings with the same id has already been loaded. + * `true`: the current settings will take precedence over any previously defined setting with this id + * `false`: the current settings will not override a previously defined setting with this id + @@ -47,10 +47,10 @@ See link:../settings.html[Settings Files] for details about the settings file it == HTTP Authentication -If any of the url you use in Ivy (especially in dependency resolvers) needs http authentication, then you have to provide the `host`, `realm`, `username` and `passwd` attributes of the configure task. These settings will then be used in any further call to Ivy tasks. +If any of the URLs you use in Ivy (especially in dependency resolvers) needs HTTP authentication, then you have to provide the `host`, `realm`, `username` and `passwd` attributes of the configure task. These settings will then be used in any further call to Ivy tasks. *Since 1.4:* -It's also possible to configure authentication settings for multiple urls. This can be done with the `<credentials>` subelements. See the examples for more details. +It's also possible to configure authentication settings for multiple URLs. This can be done with the `<credentials>` subelements. See the examples for more details. == Examples @@ -70,7 +70,7 @@ Use either `${ivy.settings.file}` if it exists, or the link:../samples/ivysettin <ivy:configure file="myconffile.xml"/> ---- -=== Configure with an url +=== Configure with an URL [source,xml] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/convertpom.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/convertpom.adoc b/asciidoc/use/convertpom.adoc index b593584..4209531 100644 --- a/asciidoc/use/convertpom.adoc +++ b/asciidoc/use/convertpom.adoc @@ -24,8 +24,8 @@ [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|pomFile|the location of the pom.xml to convert|Yes -|ivyFile|the location of the ivy.xml to generate|Yes +|pomFile|the location of the `pom.xml` to convert|Yes +|ivyFile|the location of the `ivy.xml` to generate|Yes |======= == Examples @@ -35,4 +35,4 @@ <ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml"/> ---- -Just convert an pom.xml file into an ivy.xml. +Just convert a `pom.xml` file into an `ivy.xml`. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/deliver.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/deliver.adoc b/asciidoc/use/deliver.adoc index da473e1..8e58cff 100644 --- a/asciidoc/use/deliver.adoc +++ b/asciidoc/use/deliver.adoc @@ -21,15 +21,15 @@ Deliver a resolved descriptor of the current module, and possibly perform a recu This task does two main things: -== Generate a resolved ivy file +== Generate a resolved Ivy file -This task generates a resolved descriptor of the current module, based upon the last resolve done. The resolved ivy file contains updated information about the delivered module, such as revision and status. +This task generates a resolved descriptor of the current module, based upon the last resolve done. The resolved Ivy file contains updated information about the delivered module, such as revision and status. -Moreover, all included configurations' files are included in the ivy file, and variables are replaced by their values. +Moreover, all included configurations' files are included in the Ivy file, and variables are replaced by their values. -Finally, in the resolved ivy file, dynamic revisions are replaced by the static ones that have been found during the resolve step, so the ivy file can be used later safely to obtain the same dependencies (providing that a revision uniquely identifies a module, which should be the case for proper ivy use). +Finally, in the resolved Ivy file, dynamic revisions are replaced by the static ones that have been found during the resolve step, so the Ivy file can be used later safely to obtain the same dependencies (providing that a revision uniquely identifies a module, which should be the case for proper Ivy use). -*__since 1.3__* The replacement of dynamic revisions by static ones can be turned off, so that dynamic revisions are kept in the ivy file. This is an exception to the recommended standard that published module descriptors be fully resolved, so use it with caution. +*__since 1.3__* The replacement of dynamic revisions by static ones can be turned off, so that dynamic revisions are kept in the Ivy file. This is an exception to the recommended standard that published module descriptors be fully resolved, so use it with caution. == Recursive delivery @@ -53,20 +53,20 @@ Both `dependency.published.status` and `dependency.published.version` can be eit Usually the deliver target itself triggers an another Ant build (using the `ant` task) even if this is up to you to decide. -The delivered ivy file will update its dependency revisions with those given here. +The delivered Ivy file will update its dependency revisions with those given here. == deliver and publish The `deliver` task is most of the time not called explicitly, but rather called automatically by the link:../use/publish.html[publish] task. So, when shall the deliver task be called explicitly? When you actually need to separate what is performed by the deliver task (see above), from what is performed by the `publish` task, i.e. upload a module to a repository. -And this can be particularly useful if you want to process the generated ivy file before uploading it (if you want to add automatically more information like an SCM tag used, the user who performed the release, ...). +And this can be particularly useful if you want to process the generated Ivy file before uploading it (if you want to add automatically more information like an SCM tag used, the user who performed the release, ...). It can also be useful if you want to trigger a recursive delivery and then ensure that you get the recursively delivered modules as dependencies. In this case your build order may look like this: - `ivy:configure` - `ivy:resolve` - `ivy:deliver` with recursive delivery -- `ivy:resolve` again with the ivy file generated by the recursive delivery +- `ivy:resolve` again with the Ivy file generated by the recursive delivery - do your build stuff (compile, jar, whatever) - `ivy:publish` @@ -75,24 +75,24 @@ It can also be useful if you want to trigger a recursive delivery and then ensur [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|deliverpattern|the pattern to use for ivy file delivery|No. Defaults to `${ivy.deliver.ivy.pattern}` +|deliverpattern|the pattern to use for Ivy file delivery|No. Defaults to `${ivy.deliver.ivy.pattern}` |pubrevision|the revision to use for the publication|No. Defaults to `${ivy.deliver.revision}` if set, or the revision resolved if set, or a timestamp |pubbranch|the branch to use for the publication|No. Defaults to `${ivy.deliver.branch}` if set, or the branch resolved if set, or nothing (branch info won't be updated) |pubdate|the publication date to use for the publication. This date should be either `now`, or a date given with the following pattern: `yyyyMMddHHmmss`|No. Defaults to `now` |status|the status to use for the publication|No. Defaults to `${ivy.status}` |delivertarget|the target to call for recursive delivery|No. No recursive delivery is done by default -|validate|`true` to force ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default ivy value (as configured in configuration file) +|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in settings) |replacedynamicrev|`true` to replace dynamic revisions by static ones in the delivered file, `false` to avoid this replacement *__(since 1.3)__*|No. Defaults to `true` |replaceForcedRev|`true` to replace revisions (static or dynamic) by the revision of the resolver in link:../settings/resolvers.html#common[forced mode], `false` to avoid this replacement *__(since 2.2)__*|No. Defaults to `false` |merge|if a descriptor link:../ivyfile/extends.html[extends] a parent, merge the inherited information directly into the delivered descriptor. The `extends` element itself will be commented out in the delivered descriptor. *__(since 2.2)__*|No. Defaults to `true`. -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No. Defaults to `ivy.instance`. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No. Defaults to `ivy.instance`. |conf|comma-separated list of configurations to include in the delivered file. Accepts wildcards. *__(since 2.0)__*|No. Defaults to all configurations -|generateRevConstraint|`true` to automatically generate a `revConstraint attribute in the delivered file (see the link:../ivyfile/dependency.html[dependency] page for more info about this attribute), `false` to never generate this attribute *__(since 2.1.0)__*|No. Defaults to `true` +|generateRevConstraint|`true` to automatically generate a `revConstraint` attribute in the delivered file (see the link:../ivyfile/dependency.html[dependency] page for more info about this attribute), `false` to never generate this attribute *__(since 2.1)__*|No. Defaults to `true` |======= == Example -Deliver an ivy file without the private configurations: +Deliver an Ivy file without the private configurations: [source,xml] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/dependencytree.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/dependencytree.adoc b/asciidoc/use/dependencytree.adoc index a036564..4294ed7 100644 --- a/asciidoc/use/dependencytree.adoc +++ b/asciidoc/use/dependencytree.adoc @@ -21,7 +21,7 @@ Display a dependency tree on the console. This is a link:../use/postresolvetask.html[post resolve task], with all the behaviour and attributes common to all post resolve tasks. -Please prefer the use of retrieve + standard ant path creation, which make your build more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). +Please prefer the use of retrieve + standard Ant path creation, which make your build more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). == Attributes @@ -31,8 +31,8 @@ Please prefer the use of retrieve + standard ant path creation, which make your |showEvicted|specify if evicted modules should be printed|No. Defaults to `false` |conf|a comma separated list of the configurations to take in consideration in the dependency tree|No. Defaults to the configurations resolved by the last resolve call, or `*` if no resolve was explicitly called |haltonfailure|`true` to halt the build on ivy failure, `false` to continue|No. Defaults to `true` -|validate|true to force ivy files validation against ivy.xsd, false to force no validation|No. Defaults to default ivy value (as configured in configuration file) -|settingsRef|A reference to the ivy settings that must be used by this task *(since 2.0)*|No, defaults to `ivy.instance`. +|validate|true to force ivy files validation against ivy.xsd, false to force no validation|No. Defaults to default ivy value (as configured in settings) +|settingsRef|A reference to Ivy settings that must be used by this task *(since 2.0)*|No, defaults to `ivy.instance`. |overwrite|Overwrite the value of the property if it already exist *(since 2.0)*. Before 2.0, the properties were always overwritten.|No, `false` by default. |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/findrevision.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/findrevision.adoc b/asciidoc/use/findrevision.adoc index 2ff3e49..6f9e83d 100644 --- a/asciidoc/use/findrevision.adoc +++ b/asciidoc/use/findrevision.adoc @@ -21,7 +21,7 @@ Finds the latest revision of a module matching a given version constraint. A version constraint is what is used when declaring a link:../ivyfile/dependency.html[dependency] on a module. -If the module is not found the property is not set. +If the module is not found, the property is not set. == Attributes @@ -29,11 +29,11 @@ If the module is not found the property is not set. |======= |Attribute|Description|Required |organisation|the organisation of the module to find|Yes -|module|the the name of the module to find|Yes +|module|the name of the module to find|Yes |branch|the branch of the module to find|No, defaults to the default branch for the given module |revision|the revision constraint to apply|Yes |property|the property to set with the found revision|No, defaults to `ivy.revision` -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|settingsRef|a reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. |======= == Examples @@ -43,7 +43,7 @@ If the module is not found the property is not set. <ivy:findrevision organisation="apache" module="ivy" revision="latest.integration"/> ---- -finds the latest version of ivy available in the repository and sets the property `ivy.revision` according to what was found. +finds the latest version of Ivy available in the repository and sets the property `ivy.revision` according to what was found. ''' http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/fixdeps.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/fixdeps.adoc b/asciidoc/use/fixdeps.adoc index ebf3282..49b8db6 100644 --- a/asciidoc/use/fixdeps.adoc +++ b/asciidoc/use/fixdeps.adoc @@ -24,12 +24,12 @@ The dependencies declared in an `ivy.xml` can be specified as range of revisions It is especially useful in a very dynamic environment like the link:../osgi.html[OSGi] one. -In a multi project environment some dependencies still need to be maintained loose: the one between the projects. These dependencies, as soon as they are declared in the original ivy.xml, can be kept from being fixed. In order to do so, use the inner element `keep`. +In a multi project environment some dependencies still need to be maintained loose: the ones between the projects. These dependencies, as soon as they are declared in the original ivy.xml, can be kept from being fixed. In order to do so, use the inner element `keep`. The recommended setup is then to: * have an `ivy-spec.xml` in your project which specifies the dependencies, with ranges if needed -* have an Ant target which resolve the `ivy-spec.xml` and call `fixdeps` to generate an `ivy.xml`. This target should then only be called after `ivy-spec.xml` is modified. The generated `ivy.xml` can safely be shared in a version control repository (svn, git,...). +* have an Ant target which resolves the `ivy-spec.xml` and call `fixdeps` to generate an `ivy.xml`. This target should then only be called after `ivy-spec.xml` is modified. The generated `ivy.xml` can safely be shared in a version control repository (Git, Subversion, ...). * make the entire build workflow based on the resolve of the generated `ivy.xml` This is a link:../use/postresolvetask.html[post resolve task], with all the behaviour and attributes common to all post resolve tasks. @@ -39,7 +39,7 @@ This is a link:../use/postresolvetask.html[post resolve task], with all the beha [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|tofile|The location of the ivy file to generate|Yes +|tofile|The location of the Ivy file to generate|Yes |======= == Child elements http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/info.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/info.adoc b/asciidoc/use/info.adoc index 40c30bc..c0e93e1 100644 --- a/asciidoc/use/info.adoc +++ b/asciidoc/use/info.adoc @@ -18,20 +18,20 @@ //// *__since 1.4__* -The `info` task ease the access to some essential data contained in an Ivy file without performing a dependency resolution. +The `info` task eases the access to some essential data contained in an Ivy file without performing a dependency resolution. The information is retrieved by setting Ant properties: [options="header",cols="30%,50%"] |======= |Property|Description -|ivy.organisation|The organisation of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. -|ivy.module|The name of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. -|ivy.branch|The branch of the module if any, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. -|ivy.revision|The revision of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. -|ivy.status|The status of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. -|ivy.publication|The publication time of the module, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed. *__(Since 2.2)__* -|ivy.extra.__[any extra attribute]__|Corresponding extra attribute value, as found in the link:../ivyfile/info.html[info] tag of the ivy file parsed +|ivy.organisation|The organisation of the module, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. +|ivy.module|The name of the module, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. +|ivy.branch|The branch of the module if any, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. +|ivy.revision|The revision of the module, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. +|ivy.status|The status of the module, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. +|ivy.publication|The publication time of the module, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed. *__(Since 2.2)__* +|ivy.extra.__[any extra attribute]__|Corresponding extra attribute value, as found in the link:../ivyfile/info.html[info] tag of the Ivy file parsed |ivy.configurations|A comma separated list of configurations of the module, as declared in the link:../ivyfile/configurations.html[configurations] section |ivy.public.configurations|A comma separated list of public configurations of the module, as declared in the link:../ivyfile/configurations.html[configurations] section |ivy.configuration.__[config name]__.desc|For each configuration with a description, a property is created containing this description. *__(Since 2.2)__* @@ -44,13 +44,13 @@ The information is retrieved by setting Ant properties: *__since 2.0__* -Since Ivy 2.0 this task has been enhanced to allow you to retrieve information about ivy modules in a repository. Instead of specifying a local ivy file you may specify the organisation, module, revision pattern and (optionally) the branch of the ivy module in the repository you wish to retrieve the information for. +Since Ivy 2.0 this task has been enhanced to allow you to retrieve information about Ivy modules in a repository. Instead of specifying a local Ivy file you may specify the organisation, module, revision pattern and (optionally) the branch of the Ivy module in the repository you wish to retrieve the information for. The revision pattern is what is used when declaring a link:../ivyfile/dependency.html[dependency] on a module, identical to how the link:findrevision.html[findrevision] task works. In fact this task can now be used in place of the findrevision task. If no matching module is found then no property values are set. -You may now also set the property attribute to change the first part of the property names that are set by this task e.g. if you set the property attribute to `mymodule` this task will set the ant properties `mymodule.organisation`, `mymodule.module`, `mymodule.revision` etc. +You may now also set the property attribute to change the first part of the property names that are set by this task e.g. if you set the property attribute to `mymodule` this task will set the Ant properties `mymodule.organisation`, `mymodule.module`, `mymodule.revision` etc. *__since 2.2__* @@ -61,17 +61,17 @@ Since Ivy 2.2 this task has been enhanced to also retrieve detailed information [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|file|the ivy file to parse|Yes, if you wish to parse an ivy file. -No, if you are retrieving information about a module from an ivy repository. -|organisation|the organisation of the module to find *__(since 2.0)__*|No, if you wish to parse an ivy file. -Yes, if you are retrieving information about a module from an ivy repository. -|module|the the name of the module to find *__(since 2.0)__*|No, if you wish to parse an ivy file. -Yes, if you are retrieving information about a module from an ivy repository. -|branch|the branch of the module to find *__(since 2.0)__*|No, defaults to the default branch for the given module if you are retrieving information about a module from an ivy repository. -|revision|the revision constraint to apply *__(since 2.0)__*|No, if you wish to parse an ivy file. -Yes, if you are retrieving information about a module from an ivy repository. +|file|the Ivy file to parse|Yes, if you wish to parse an Ivy file. +No, if you are retrieving information about a module from an Ivy repository. +|organisation|the organisation of the module to find *__(since 2.0)__*|No, if you wish to parse an Ivy file. +Yes, if you are retrieving information about a module from an Ivy repository. +|module|the the name of the module to find *__(since 2.0)__*|No, if you wish to parse an Ivy file. +Yes, if you are retrieving information about a module from an Ivy repository. +|branch|the branch of the module to find *__(since 2.0)__*|No, defaults to the default branch for the given module if you are retrieving information about a module from an Ivy repository. +|revision|the revision constraint to apply *__(since 2.0)__*|No, if you wish to parse an Ivy file. +Yes, if you are retrieving information about a module from an Ivy repository. |property|the name to use as the base of the property names set by this task *__(since 2.0)__*|No, will default to `ivy` if not set. -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. |======= == Examples @@ -132,7 +132,7 @@ ivy.artifact.2.conf=default ivy.artifact.2.extra.data=client ---- -Given the same ivy module in a repository: +Given the same Ivy module in a repository: [source,xml] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/install.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/install.adoc b/asciidoc/use/install.adoc index d8fbf69..103ca74 100644 --- a/asciidoc/use/install.adoc +++ b/asciidoc/use/install.adoc @@ -21,7 +21,7 @@ Installs a module and all its dependencies in a resolver. *__since 1.3__* The module to install should be available in a resolver, and will be installed in another resolver which should support publish. -This is particularly useful for users who only have a private repository, and want to benefit from public repositories from time to time. In this case, when a module is missing in the private repository, a call to install let download the module from a public repository not usually used for dependency resolution, and install it and its dependencies in the private repository. +This is particularly useful for users who only have a private repository, and want to benefit from public repositories from time to time. In this case, when a module is missing in the private repository, a call to install lets download the module from a public repository not usually used for dependency resolution, and install it and its dependencies in the private repository. For more details about this task and its usage see the link:../tutorial/build-repository.html[build repository tutorial] @@ -36,13 +36,13 @@ For more details about this task and its usage see the link:../tutorial/build-re |module|the name of the module to install|Yes |branch|the branch of the module to install *__since 2.0__*|No, defaults to default branch with exact matcher, `*` with any other matcher |revision|the revision of the module to install|Yes -|type|the type(s) of artefact(s) to install. You can give multiple values separated by commas|No, defaults to `*` meaning all types +|type|the type(s) of artifact(s) to install. You can give multiple values separated by commas|No, defaults to `*` meaning all types |conf|the configurations to install. Only the dependencies of the specified configurations will be installed. *__since 2.3__*|No, defaults to `*` meaning all configurations -|validate|`true` to force ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default ivy value (as configured in configuration file) +|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in settings) |overwrite|`true` to override modules already present in the destination resolver, `false` otherwise|No, defaults to `false` |transitive|`true` to install the module and all its transitive dependencies, `false` to install only the module|No, defaults to `false` |matcher|the name of the matcher to use to find the modules to install|No, defaults to `exact` -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. |haltonfailure|`true` to fail build on unresolved dependencies *__since 2.0__*|No, defaults to `true` |installOriginalMetadata|`true` to install original metadata (if available). If the module has been originally resolved from a m2 repository, the original metadata is the original POM file *__since 2.4__*|No, defaults to `false` |======= @@ -54,4 +54,4 @@ For more details about this task and its usage see the link:../tutorial/build-re <ivy:install organisation="apache" module="commons-lang" revision="2.0" from="ivyrep" to="myfsresolver"/> ---- -Installs the module commons-lang from apache in revision 2.0 in the resolver myfsresolver. The module is found in the resolver named `ivyrep`. +Installs the module `commons-lang` from `apache` in revision 2.0 in the resolver `myfsresolver`. The module is found in the resolver named `ivyrep`. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/listmodules.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/listmodules.adoc b/asciidoc/use/listmodules.adoc index a94e824..48fb27e 100644 --- a/asciidoc/use/listmodules.adoc +++ b/asciidoc/use/listmodules.adoc @@ -18,11 +18,11 @@ //// *__since 1.4__* -Finds the list of modules in the repository matching some criteria and set a corresponding list of properties in ant. +Finds the list of modules in the repository matching some criteria and sets a corresponding list of properties in Ant. The criteria is set by given patterns matching the organisation, name branch and revision of the modules to find. -To know if a module matches the criteria ivy will use the configured link:../concept.html#matcher[pattern matcher]. +To know if a module matches the criteria, Ivy will use the configured link:../concept.html#matcher[pattern matcher]. == Attributes @@ -36,8 +36,8 @@ To know if a module matches the criteria ivy will use the configured link:../con |matcher|the name of the pattern matcher to use for matching the modules fields|No. Defaults to `exactOrRegexp`. |property|the pattern of the property to set when a module is found|Yes |value|The pattern of the value to set when a module is found|Yes -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. -|resolver|The name of the resolver to use for searching the modules *__(since 2.2.0)__*|No, all available resolvers will be used by default. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|resolver|The name of the resolver to use for searching the modules *__(since 2.2)__*|No, all available resolvers will be used by default. |======= == Examples http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/makepom.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/makepom.adoc b/asciidoc/use/makepom.adoc index ddf0a21..e9ca0f4 100644 --- a/asciidoc/use/makepom.adoc +++ b/asciidoc/use/makepom.adoc @@ -18,18 +18,18 @@ //// *__since 2.0__* -The `makepom` task allows to convert an ivy file to a pom file. +The `makepom` task allows to convert an Ivy file to a POM file. -An example of use is to publish an Ivy managed module to a maven 2 repository. +An example of use is to publish an Ivy managed module to a Maven 2 repository. -_Note that all Ivy features are not supported by maven poms, so the converted pom may not resolve to the exact same dependencies as the original ivy file._ +_Note that all Ivy features are not supported by Maven POMs, so the converted POM may not resolve to the exact same dependencies as the original Ivy file._ *__since 2.2__* It is possible to specify a template file defining the structure of the generated POM. The following processing is done on this template: * properties like `${property.name}` are replaced if they are defined in Ant or by the `ivy:makepom` task (see below for the standard properties) * lines containing the string `SKIP_LINE` are skipped. -* the defined dependencies will be added to the first `<dependencies>` element encountered in the pom template. If the template doesn't contain a `<dependencies>` element, it is generated a the end of the pom. +* the defined dependencies will be added to the first `<dependencies>` element encountered in the POM template. If the template doesn't contain a `<dependencies>` element, it is generated a the end of the POM. The `ivy:makepom` task defines following properties that can be used in the template. @@ -70,16 +70,16 @@ ${ivy.pom.header} [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|ivyfile|the source ivy file to convert|Yes -|pomfile|the destination pom file to write|Yes -|templatefile|the template file to use when generating the pom *__(since 2.2)__*|No, defaults to the internal template file. -|artifactName|The name of the artifact which is represented by the generated pom file. *__(since 2.2)__*|No, defaults to the module name in the source ivy file. -|artifactPackaging|The packaging of the artifact which is represented by the generated pom file. *__(since 2.2)__*|No, the artifact type is taken by default. Defaults to `pom` if no such artifact is defined. -|conf|a comma separated list of the configurations to include in the generated pom. Wildcards are supported here. *__(since 2.2)__*|No, defaults to all configurations. -|settingsRef|A reference to the ivy settings that must be used by this task|No, defaults to `ivy.instance`. +|ivyfile|the source Ivy file to convert|Yes +|pomfile|the destination POM file to write|Yes +|templatefile|the template file to use when generating the POM *__(since 2.2)__*|No, defaults to the internal template file. +|artifactName|The name of the artifact which is represented by the generated POM file. *__(since 2.2)__*|No, defaults to the module name in the source Ivy file. +|artifactPackaging|The packaging of the artifact which is represented by the generated POM file. *__(since 2.2)__*|No, the artifact type is taken by default. Defaults to `pom` if no such artifact is defined. +|conf|a comma separated list of the configurations to include in the generated POM. Wildcards are supported here. *__(since 2.2)__*|No, defaults to all configurations. +|settingsRef|A reference to Ivy settings that must be used by this task|No, defaults to `ivy.instance`. |printIvyInfo|Add some information about Ivy to the generated POM. *__(since 2.2)__*|No, defaults to `true`. -|headerFile|the header of the generated pom file|No -|description|The description that will be added to the generated pom. *__(since 2.2)__*|No, defaults to no description. Since 2.5, defaults to the description in the source ivy file. +|headerFile|the header of the generated POM file|No +|description|The description that will be added to the generated POM. *__(since 2.2)__*|No, defaults to no description or *__(since 2.5)__* to the description in the source Ivy file. |======= == Child elements @@ -113,6 +113,6 @@ These elements takes the following attributes: + </ivy:makepom> ---- -Converts `+++${basedir}/path/to/ivy.xml+++` to a pom and writes the result to `+++${basedir}/path/to/module.pom+++`. The configuration 'default' in the parsed ivy file will be mapped to the scope 'compile', the configuration 'runtime' will be mapped to 'runtime', and other configurations will be excluded. +Converts `+++${basedir}/path/to/ivy.xml+++` to a POM and writes the result to `+++${basedir}/path/to/module.pom+++`. The configuration 'default' in the parsed Ivy file will be mapped to the scope 'compile', the configuration 'runtime' will be mapped to 'runtime', and other configurations will be excluded. The __com.acme.acme-logging__ artifact with version 1.0 will be added as an optional dependency. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/postresolvetask.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/postresolvetask.adoc b/asciidoc/use/postresolvetask.adoc index f4ae1ad..60e663a 100644 --- a/asciidoc/use/postresolvetask.adoc +++ b/asciidoc/use/postresolvetask.adoc @@ -17,7 +17,7 @@ under the License. //// -Several tasks in Ivy are considered as post resolve task and share a common behaviour and settings accordingly. +Several tasks in Ivy are considered as post resolve tasks and share a common behaviour and settings accordingly. These tasks are: @@ -27,13 +27,13 @@ These tasks are: * link:../use/artifactproperty.html[artifactproperty] *__(since 2.0)__* * link:../use/artifactreport.html[artifactreport] *__(since 2.0)__* -All these tasks will trigger automatically a resolve if: +All these tasks will trigger a resolve automatically if: -* none has already been called in the current build with the attribute keep set to true (see below) +* none has already been called in the current build with the attribute `keep` set to `true` (see below) * organisation and module are not set -*__Since Ivy 1.4__*, there are two ways to run a link:../use/resolve.html[resolve]: with an ivy file, or with the inline mode. -When you call resolve with an ivy file, the default for it is to keep the resolved data for use by the subsequent post resolve tasks. When you run an inline resolve, the default is not to keep the data. You can override this behaviour by setting the keep attribute as you like. +*__Since Ivy 1.4__*, there are two ways to run a link:../use/resolve.html[resolve]: with an Ivy file, or with the inline mode. +When you call resolve with an Ivy file, the default for it is to keep the resolved data for use by the subsequent post resolve tasks. When you run an inline resolve, the default is not to keep the data. You can override this behaviour by setting the keep attribute as you like. If you want to to reuse the resolved data obtained through a call to resolve in another build (i.e. not the current one), then you have to set the organisation and module attributes. This work only if the cache was not cleaned since your last resolve call. This does not work with inline calls, which must be performed in the same build. @@ -46,20 +46,20 @@ The attributes listed are then mostly used only if a resolve is triggered automa |Attribute|Description|Required |conf|a comma separated list of the configurations to retrieve or `$$*$$`. + *__Since 2.0__* you can also use `$$*(public)$$` or `$$*(private)$$`. Note that `$$*$$` is interpreted as `$$*(public)$$` when `inline` is `true`.|No. Defaults to the configurations resolved by the last resolve call, or `$$*$$` if no resolve was explicitly called -|inline|`true` to use inline mode, `false` to resolve an ivy file *__(since 1.4)__*|No. defaults `false` +|inline|`true` to use inline mode, `false` to resolve an Ivy file *__(since 1.4)__*|No. defaults `false` |organisation|the organisation of the module to retrieve. This usually doesn't need to be set since it defaults to the last resolved one, except for inline mode where it is required.|Yes in inline mode, otherwise no, it then defaults to last resolved module name |module|the name of the module to retrieve. This usually doesn't need to be set since it defaults to the last resolved one, except for inline mode where it is required.|Yes in inline mode, otherwise no, it then defaults to last resolved module name |revision|the revision constraint of the module to retrieve. Used only in inline mode. *__since 1.4__*|No. Defaults to latest.integration |branch|the name of the branch to resolve in inline mode *__(since 2.1)__*|Defaults to no branch in inline mode, nothing in standard mode. -|changing|indicates that the module may change when resolving in inline mode. See link:../concept.html#change[cache and change management] for details. Ignored when resolving in standard mode. *__(since 2.2.0)__*|No. Defaults to `false`. +|changing|indicates that the module may change when resolving in inline mode. See link:../concept.html#change[cache and change management] for details. Ignored when resolving in standard mode. *__(since 2.2)__*|No. Defaults to `false`. |transitive|`true` to resolve dependencies transitively, `false` otherwise *__since 1.4__*|No. Defaults to `true` |resolveMode|the link:../use/resolve.html[resolve mode] to use when an automatic resolve is triggered *__(since 2.1)__*|No. defaults to using the resolve mode set in the link:../settings.html[settings] -|keep|`true` to keep the results of the automatic resolve in memory, `false` to discard them. When this is `false`, the standard ivy properties won't be set and other post-resolve tasks (like `retrieve` and `cachepath`) won't be able to reuse the results of this resolve!|No. defaults to `false` for an inline resolve and to `true` in any other case -|haltonfailure|`true` to halt the build on ivy failure, `false` to continue|No. Defaults to `true` -|validate|`true` to force ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default ivy value (as configured in configuration file) +|keep|`true` to keep the results of the automatic resolve in memory, `false` to discard them. When this is `false`, the standard Ivy properties won't be set and other post-resolve tasks (like `retrieve` and `cachepath`) won't be able to reuse the results of this resolve!|No. defaults to `false` for an inline resolve and to `true` in any other case +|haltonfailure|`true` to halt the build on Ivy failure, `false` to continue|No. Defaults to `true` +|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in settings) |refresh|`true` to force Ivy to resolve dynamic revision in this resolve process, `false` to use cached resolved revision *__since 2.1__*|No. defaults to `false` |file|the file to resolve if a resolve is necessary *__since 2.0__*|No. Defaults to the previous resolved Ivy file or to `${ivy.dep.file}` -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance` +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance` |resolveId|The id which was used for a previous resolve, or the resolveId if a new resolve is performed *__(since 2.0)__*|No, defaults to `[org]-[module]`. |log|the log setting to use during the resolve process. *__(since 2.0)__* @@ -94,4 +94,4 @@ There is one important difference with the ivy.xml's link:../ivyfile/dependencie <taskdef resource="emma_ant.properties" classpathref="emma.classpath"/> ---- -Resolves the Emma module in version 2.0.4217, constructs an Ant path with the corresponding artifacts, and then define the Emma tasks using this path. +Resolves the Emma module in version 2.0.4217, constructs an Ant path with the corresponding artifacts, and then defines the Emma tasks using this path. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/publish.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/publish.adoc b/asciidoc/use/publish.adoc index 7f61f26..1509579 100644 --- a/asciidoc/use/publish.adoc +++ b/asciidoc/use/publish.adoc @@ -17,15 +17,15 @@ under the License. //// -Publishes the current module's link:../ivyfile/publications.html[artifacts] and the link:../ivyfile.html#resolved[resolved descriptor] (delivered ivy file). +Publishes the current module's link:../ivyfile/publications.html[artifacts] and the link:../ivyfile.html#resolved[resolved descriptor] (delivered Ivy file). This task is meant to publish the current module descriptor together with its declared publication artifacts to a repository. All the artifacts must have been created _before_ calling this task. It does not create the artifacts themselves, but expects to find them at the location indicated by the artifacts pattern. -The target repository is given through the name of a resolver declared in current ivy settings. See link:../settings.html[Settings Files] for details about resolver supporting artifact publishing. +The target repository is given through the name of a resolver declared in current Ivy settings. See link:../settings.html[Settings Files] for details about resolver supporting artifact publishing. -It also publishes the delivered ivy file (except if you don't want), and even deliver it, if it has not been done with a previous deliver call or if forcedeliver is set to true. That's why this task takes some parameters useful only for delivery. See the illustration below: +It also publishes the delivered Ivy file (except if you don't want), and even deliver it, if it has not been done with a previous deliver call or if forcedeliver is set to true. That's why this task takes some parameters useful only for delivery. See the illustration below: image::../images/ivy-publish-fc.png[] @@ -44,21 +44,21 @@ The source artifact pattern can be specified either as an attribute on the task |resolver|the name of the resolver to use for publication|Yes |pubrevision|the revision to use for the publication|No. Defaults to the `${ivy.deliver.revision}` |pubbranch|the branch to use for the publication|No. Defaults to the `${ivy.deliver.branch}` -|forcedeliver|`true` to force the implicit call to deliver, `false` to do it only if the ivy file to publish doesn't exist yet *__(since 1.4)__*|No. Defaults to `false` -|update|`true` to update ivy file metadata (revision, branch, publication date and status) before publishing, `false` otherwise. This is usually not necessary when using deliver before publish.|No. Defaults to `false` +|forcedeliver|`true` to force the implicit call to deliver, `false` to do it only if the Ivy file to publish doesn't exist yet *__(since 1.4)__*|No. Defaults to `false` +|update|`true` to update Ivy file metadata (revision, branch, publication date and status) before publishing, `false` otherwise. This is usually not necessary when using deliver before publish.|No. Defaults to `false` |merge|if this descriptor link:../ivyfile/extends.html[extends] a parent, merge the inherited information directly into this descriptor on publish. The __extends__ element itself will be commented out in the published descriptor. *__(since 2.2)__*|No. Defaults to false -|validate|`true` to force ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default ivy value (as configured in link:../settings.html[settings file]) +|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in link:../settings.html[settings file]) |replacedynamicrev|`true` to replace dynamic revisions by static ones in the delivered file, `false` to avoid this replacement *__(since 1.3)__*|No. Defaults to `true` -|publishivy|`true` to publish delivered ivy file, `false` otherwise|No. Defaults to `true` +|publishivy|`true` to publish delivered Ivy file, `false` otherwise|No. Defaults to `true` |conf|A comma separated list of configurations to publish *__(since 1.4.1)__*. Accepts wildcards *__(since 2.2)__*.|No. Defaults to all configurations -|overwrite|`true` to overwrite files in repository if the revision already exist, `false` to let it as is|No. Defaults to `false` +|overwrite|`true` to overwrite files in repository if the revision already exists, `false` to let it as is|No. Defaults to `false` |warnonmissing|`true` to warn when artifacts to be published are missing|No. Defaults to `true` |haltonmissing|`true` to halt build when artifacts to be published are missing|No. Defaults to `true` -|srcivypattern|the pattern to use to find ivy file to publish, and even deliver if necessary *__(since 1.2)__*|No. Defaults to the value of `artifactspattern` +|srcivypattern|the pattern to use to find Ivy file to publish, and even deliver if necessary *__(since 1.2)__*|No. Defaults to the value of `artifactspattern` |pubdate|the publication date to use for the delivery, if necessary. This date should be either `now`, or a date given with the following pattern: `yyyyMMddHHmmss`|No. Defaults to `now` |status|the status to use for the delivery, if necessary|No. Defaults to `${ivy.status}` |delivertarget|the target to call for recursive delivery|No. No recursive delivery is done by default -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, default to `ivy.instance`. +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, default to `ivy.instance`. |======= == Child elements @@ -66,7 +66,7 @@ The source artifact pattern can be specified either as an attribute on the task [options="header"] |======= |Element|Description|Cardinality -|artifact|Describe additional artifacts to publish. These elements can have any attribute: standard artifact attributes and (since 2.2) extra attributes are supported.|0..n +|artifact|Describe additional artifacts to publish. These elements can have any attributes: standard artifact attributes and *__(since 2.2)__* extra attributes are supported.|0..n |artifacts|Specify the pattern used to find the artifact. These elements have a `pattern` attribute containing the pattern used to find the artifact.|0..n |======= http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/report.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/report.adoc b/asciidoc/use/report.adoc index 9a64f6f..86ae3f9 100644 --- a/asciidoc/use/report.adoc +++ b/asciidoc/use/report.adoc @@ -19,14 +19,14 @@ Generates reports of dependency resolving. One report per configuration is generated, but all reports generated together are hyperlinked one to each other. -This task should be used only after a call to resolve, even if the call was not done during the same ant build. -In fact, this task uses xml report generated by resolve in cache. So if you call resolve on a module for a given configuration, you can call report safely on this module and this configuration as long as you do not clean your ivy cache. +This task should be used only after a call to resolve, even if the call was not done during the same Ant build. +In fact, this task uses XML report generated by resolve in cache. So if you call resolve on a module for a given configuration, you can call report safely on this module and this configuration as long as you do not clean your Ivy cache. If you want to have an idea of what reports look like, check this very simple link:../samples/jayasoft-ivyrep-example-default.html[example]. -The task also generates a graphml file which can be loaded with the free link:http://www.yworks.com/en/products_yed_about.htm[yEd] graph editor. +The task also generates a GraphML file which can be loaded with the free link:http://www.yworks.com/en/products_yed_about.htm[yEd] graph editor. Then following a few link:../yed.html[simple steps] you can obtain a graph like this link:../samples/jayasoft-ivyrep-example-default.jpg[one]. -*__since 1.4__* If a custom XSL is specified, it's possible to specify additional parameters to the stylesheet. +*__since 1.4__* If a custom XSLT is specified, it's possible to specify additional parameters to the stylesheet. == Attributes @@ -36,21 +36,21 @@ Then following a few link:../yed.html[simple steps] you can obtain a graph like |todir|the directory to which reports should be generated|No, defaults to `${ivy.report.todir}`, or execution directory if not defined |outputpattern|the generated report names pattern|No, defaults to `${ivy.report.output.pattern}`, or `[organisation]-[module]-[conf].[ext]` if not defined |xsl|`true` to generate a report (by default html report) using xslt, `false` otherwise *__since 1.3__*|No, defaults to `true` -|xml|`true` to generate a xml report, `false` otherwise *__since 1.3__*|No, defaults to `false` -|graph|`true` to generate graphml files, `false` otherwise|No, defaults to `true` -|dot|`true` to generate link:http://www.graphviz.org/[graphviz dot] files, `false` otherwise *__since 1.4__*|No, defaults to `false` -|conf|a comma separated list of the configurations for which a report should be generated|No. Defaults to the configurations resolved by the last resolve call (during same ant build), or `${ivy.resolved.configurations}` if no resolve was called +|xml|`true` to generate an XML report, `false` otherwise *__since 1.3__*|No, defaults to `false` +|graph|`true` to generate GraphML files, `false` otherwise|No, defaults to `true` +|dot|`true` to generate link:http://www.graphviz.org/[Graphviz DOT] files, `false` otherwise *__since 1.4__*|No, defaults to `false` +|conf|a comma separated list of the configurations for which a report should be generated|No. Defaults to the configurations resolved by the last resolve call (during same Ant build), or `${ivy.resolved.configurations}` if no resolve was called |organisation|the name of the organisation of the module for which report should be generated|No, unless resolveId has not been specified and no resolve was called during the build. Defaults to last resolved module organisation. |module|the name of the module for which report should be generated|No, unless resolveId has not been specified and no resolve was called during the build. Defaults to last resolved module. -|validate|true to force ivy files validation against ivy.xsd, false to force no validation|No. Defaults to default ivy value (as configured in configuration file) -|xslfile|indicates which xsl file should be used to generate the report|No, defaults to ivy provided xsl which generates html report -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|validate|true to force Ivy files validation against ivy.xsd, false to force no validation|No. Defaults to default Ivy value (as configured in settings) +|xslfile|indicates which xsl file should be used to generate the report|No, defaults to Ivy provided xsl which generates html report +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. |resolveId|The id which was used for a previous resolve *__(since 2.0)__*|No, defaults to `[org]-[module]`. |======= == Examples -To generate a HTML and graphml report: +To generate a HTML and GraphML report: [source,xml] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/repreport.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/repreport.adoc b/asciidoc/use/repreport.adoc index 1668dc8..29ecda9 100644 --- a/asciidoc/use/repreport.adoc +++ b/asciidoc/use/repreport.adoc @@ -17,13 +17,13 @@ under the License. //// -Generates reports about dependencies among several modules in the repository (repreport stands for repository report).*__since 1.4__* +Generates reports about dependencies among several modules in the repository (repreport stands for repository report). *__since 1.4__* This task is similar to the link:../use/report.html[report] task, except that instead of working on a single module you just resolved, it works with a set of modules in your repository. Note that the set of modules for which you generate the report is determined by setting organisation module and revision and using a matcher, but also by the dependencies of these modules. No dependency is excluded. -Usually the most useful report is a graph, you can generate either a graphml file that you can then easily link:../yed.html[layout using yEd], or a dot file which is the format recognized by graphviz, which is a free tool which does automatic graph layout, and can thus be used to generate automatically a GIF or PNG of the dependencies between all your modules. +Usually the most useful report is a graph, you can generate either a GraphML file that you can then easily link:../yed.html[layout using yEd], or a DOT file which is the format recognized by Graphviz, which is a free tool that does automatic graph layout, and can thus be used to generate automatically a GIF, PNG or SVG of the dependencies between all your modules. *Limitation*: this task requires to be able to browse the repository, and is thus limited to resolvers supporting repository listing. In particular, it means it doesn't work to report all organizations in a repository using m2compatible mode. Moreover, to be able to list organizations, this task requires an [organisation] token in the resolver(s) used. @@ -39,20 +39,20 @@ Moreover, to be able to list organizations, this task requires an [organisation] |revision|The revision of the modules for which the report should be generated. Only one revision per module will be used, so most of the time keeping the default (`latest.integration`) is the best thing to do, because it's not very easy to specify only one revision for several modules.|No, defaults to `latest.integration` |todir|the directory to which reports should be generated|No, defaults to execution directory |outputname|the name to use for the generate file (without extension)|No, defaults to `ivy-repository-report` -|xml|`true` to generate a xml report, `false` otherwise|No, defaults to `true` -|xsl|`true` to generate a report using xslt, `false` otherwise|No, defaults to `false` -|xslfile|indicates which xsl file should be used to generate the report|Yes if you want to use xsl transformation -|xslext|indicates the extension to use when generating report using xsl|No defaults to `html` -|graph|`true` to generate graphml file, `false` otherwise|No, defaults to `false` -|dot|`true` to generate graphviz dot format file, `false` otherwise|No, defaults to `false` +|xml|`true` to generate a XML report, `false` otherwise|No, defaults to `true` +|xsl|`true` to generate a report using XSLT, `false` otherwise|No, defaults to `false` +|xslfile|indicates which xsl file should be used to generate the report|Yes, if you want to use XSLT +|xslext|indicates the extension to use when generating report using XSLT|No, defaults to `html` +|graph|`true` to generate GraphML file, `false` otherwise|No, defaults to `false` +|dot|`true` to generate Graphviz DOT format file, `false` otherwise|No, defaults to `false` |matcher|the name of the matcher to use for matching modules names and organisations in your repository|No. Defaults to `exactOrRegexp` -|validate|`true` to force ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default ivy value (as configured in configuration file) -|settingsRef|A reference to the ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. +|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in settings) +|settingsRef|A reference to Ivy settings that must be used by this task *__(since 2.0)__*|No, defaults to `ivy.instance`. |======= == Examples -To generate a xml report for all the latest versions of all the modules in your repository: +To generate a XML report for all the latest versions of all the modules in your repository: [source,xml] ---- @@ -61,7 +61,7 @@ To generate a xml report for all the latest versions of all the modules in your ''' -To generate a graphml report for all the latest versions of all the modules in your repository: +To generate a GraphML report for all the latest versions of all the modules in your repository: [source,xml] ---- @@ -70,7 +70,7 @@ To generate a graphml report for all the latest versions of all the modules in y ''' -To generate a xml report for all the latest versions of the modules from the organisation foo in your repository: +To generate a XML report for all the latest versions of the modules from the organisation foo in your repository: [source,xml] ---- @@ -79,7 +79,7 @@ To generate a xml report for all the latest versions of the modules from the org ''' -To generate a xml report for all the versions on the 1.x stream of the modules named bar* from the organisation foo in your repository: +To generate a XML report for all the versions on the 1.x stream of the modules named bar* from the organisation foo in your repository: [source,xml] ----
