http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial.adoc b/asciidoc/tutorial.adoc index 5a46f96..208e829 100644 --- a/asciidoc/tutorial.adoc +++ b/asciidoc/tutorial.adoc @@ -37,27 +37,26 @@ OK, you've just seen how easy it is to take your first step with Ivy. Go ahead w The following tutorials are available: -* link:tutorial/start.html[Quick Start] + +* link:tutorial/start.html[Quick Start] + Guides you through your very first steps with ivy. -* link:tutorial/defaultconf.html[Adjusting default settings] + +* link:tutorial/defaultconf.html[Adjusting default settings] + Gives you a better understanding of the default settings and shows you how to customize them to your needs. -* link:tutorial/multiple.html[Multiple Resolvers] + +* link:tutorial/multiple.html[Multiple Resolvers] + Teaches you how to configure Ivy to find its dependencies in multiple places. -* link:tutorial/dual.html[Dual Resolver] + +* link:tutorial/dual.html[Dual Resolver] + Helps you configure Ivy to find ivy files in one place and artifacts in another. -* link:tutorial/dependence.html[Project dependencies] + +* link:tutorial/dependence.html[Project dependencies] + A starting point for using Ivy in a multi-project environment. -* link:tutorial/multiproject.html[Using Ivy in multiple projects environment] + +* link:tutorial/multiproject.html[Using Ivy in multiple projects environment] + A more complex example demonstrating the use of Ant+Ivy in a multi-project environment. * link:tutorial/conf.html[Using Ivy Module Configurations] + Shows you how to use configurations in an ivy file to define sets of artifacts. -* link:tutorial/build-repository.html[Building a repository] + +* link:tutorial/build-repository.html[Building a repository] + Shows you how to build your own enterprise repository. -
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/build-repository.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/build-repository.adoc b/asciidoc/tutorial/build-repository.adoc index 95f73bd..4f29860 100644 --- a/asciidoc/tutorial/build-repository.adoc +++ b/asciidoc/tutorial/build-repository.adoc @@ -28,7 +28,7 @@ To demonstrate this, we will first use a basic ivy settings file to show how it The project that we will use is pretty simple. It is composed of an Ant build file, and two ivy settings files. -Here are the public targets that we will use: +Here are the public targets that we will use: [source,shell] ---- @@ -57,5 +57,3 @@ This project is accessible in the link:https://git-wip-us.apache.org/repos/asf?p Next steps: link:../tutorial/build-repository/basic.html[Basic repository copy] link:../tutorial/build-repository/advanced.html[Using namespaces] - - http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/build-repository/advanced.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/build-repository/advanced.adoc b/asciidoc/tutorial/build-repository/advanced.adoc index 61b82f2..0558797 100644 --- a/asciidoc/tutorial/build-repository/advanced.adoc +++ b/asciidoc/tutorial/build-repository/advanced.adoc @@ -17,13 +17,13 @@ under the License. //// -Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, like when the source and destination repositories don't follow the same naming conventions. +Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, like when the source and destination repositories don't follow the same naming conventions. == On the road to a professional repository -In this section, you will learn how to build a *professional* repository. What is a *professional* repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer correct, useable, configurations and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository. +In this section, you will learn how to build a *professional* repository. What is a *professional* repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer correct, usable, configurations and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository. We have seen in the previous example, that we could use some public repositories to begin to build our own repository. Nevertheless, the result is not always the expected one, especially concerning the naming rules used. This problem is pretty normal when you have an existing repository, and want to benefit from large public repositories which do not follow the same naming conventions. It also shows up because many public repositories do not use a consistent naming scheme. For example, why don't all the apache commons modules use the org.apache.commons organization? Well.. for historical reasons. But if you setup your own repository, you may not want to suffer from the mistakes of history. @@ -85,8 +85,8 @@ Actually, Ivy uses the same repository as before for the source repository, with [source] ---- -<ibiblio name="libraries" - root="${ibiblio-maven2-root}" +<ibiblio name="libraries" + root="${ibiblio-maven2-root}" m2compatible="true" namespace="maven2" /> @@ -105,14 +105,14 @@ For the namespace we call __maven2__, we have declared several rules. Below is o <rule> <!-- imported apache maven1 projects --> <fromsystem> <src org="apache" module=".+"/> - + <dest org="$m0" module="$m0"/> </fromsystem> <tosystem> - <src org="commons-.+" module="commons-.+" /> - <src org="ant.*" module="ant.*" /> + <src org="commons-.+" module="commons-.+"/> + <src org="ant.*" module="ant.*"/> ... - <src org="xmlrpc" module="xmlrpc" /> + <src org="xmlrpc" module="xmlrpc"/> <dest org="apache" module="$m0"/> </tosystem> @@ -132,7 +132,7 @@ and for revisions : $r0, $r1, ... ==== -To understand namespaces, +To understand namespaces, * *fromsystem :* we define here that the projects defined in the system namespace under the organization called "apache" are transformed into the destination namespace into projects whose organization is named with the module name, whatever the revision is. For example, the project apache#commons-lang;1.0 in the system namespace will be translated into commons-lang#commons-lang;1.0 in the maven2 resolver namespace. + @@ -142,7 +142,7 @@ To understand namespaces, OK, you should now get the idea behind namespaces, so go ahead and look at the `ivysettings-advanced.xml` file in this example. You can test the installation of a module and its dependencies using namespaces. -Run +Run [source] ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/build-repository/basic.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/build-repository/basic.adoc b/asciidoc/tutorial/build-repository/basic.adoc index 26cd323..dfe6a16 100644 --- a/asciidoc/tutorial/build-repository/basic.adoc +++ b/asciidoc/tutorial/build-repository/basic.adoc @@ -30,10 +30,10 @@ The ivy settings file that we will use is very simple here. It defines two resol <ivysettings> <settings defaultResolver="libraries" - defaultConflictManager="all" /> <!-- in order to get all revisions without any eviction --> - <caches defaultCacheDir="${ivy.cache.dir}/no-namespace" /> + defaultConflictManager="all"/> <!-- in order to get all revisions without any eviction --> + <caches defaultCacheDir="${ivy.cache.dir}/no-namespace"/> <resolvers> - <ibiblio name="libraries" m2compatible="true" /> + <ibiblio name="libraries" m2compatible="true"/> <filesystem name="my-repository"> <ivy pattern="${dest.repo.dir}/no-namespace/[organisation]/[module]/ivys/ivy-[revision].xml"/> <artifact pattern="${dest.repo.dir}/no-namespace/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/> @@ -53,9 +53,9 @@ Let's have a look at the _maven2_ target. <target name="maven2" depends="init-ivy" description="--> install module from maven 2 repository"> - <ivy:install settingsRef="basic.settings" - organisation="commons-lang" module="commons-lang" revision="1.0" - from="${from.resolver}" to="${to.resolver}" /> + <ivy:install settingsRef="basic.settings" + organisation="commons-lang" module="commons-lang" revision="1.0" + from="${from.resolver}" to="${to.resolver}"/> </target> ---- @@ -96,11 +96,11 @@ The `maven2-deps` target is very similar to the one described above, except that [source] ---- - <target name="maven2-deps" depends="init-ivy" + <target name="maven2-deps" depends="init-ivy" description="--> install module from maven 2 repository with dependencies"> - <ivy:install settingsRef="basic.settings" - organisation="org.hibernate" module="hibernate" revision="3.2.5.ga" - from="${from.resolver}" to="${to.resolver}" transitive="true" /> + <ivy:install settingsRef="basic.settings" + organisation="org.hibernate" module="hibernate" revision="3.2.5.ga" + from="${from.resolver}" to="${to.resolver}" transitive="true"/> </target> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/conf.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/conf.adoc b/asciidoc/tutorial/conf.adoc index 39aa94d..6ceee55 100644 --- a/asciidoc/tutorial/conf.adoc +++ b/asciidoc/tutorial/conf.adoc @@ -29,7 +29,7 @@ Source code is available in `src/example/configurations/multi-projects`. We have two projects : - filter-framework is a library that defines an api to filter String arrays and two implementations of this api. - myapp is a very small app that uses filter-framework. - + The filter-framework library project produces 3 artifacts: - the api jar, - an implementation jar with no external dependencies, @@ -61,7 +61,7 @@ The first project we'll look at in this tutorial is filter-framework. In order t <publications> <artifact name="filter-api" type="jar" conf="api" ext="jar"/> <artifact name="filter-hmimpl" type="jar" conf="homemade-impl" ext="jar"/> - <artifact name="filter-ccimpl" type="jar" conf="cc-impl" ext="jar"/> + <artifact name="filter-ccimpl" type="jar" conf="cc-impl" ext="jar"/> </publications> <dependencies> <dependency org="commons-collections" name="commons-collections" rev="3.1" conf="cc-impl->default"/> @@ -111,13 +111,13 @@ Now that we have shipped (published) our fantastic filter library, we want to us <ivy-module version="1.0"> <info organisation="org.apache" module="myapp"/> - + <configurations> - <conf name="build" visibility="private" description="compilation only need api jar" /> - <conf name="noexternaljar" description="use only company jar" /> - <conf name="withexternaljar" description="use company jar and third party jars" /> + <conf name="build" visibility="private" description="compilation only need api jar"/> + <conf name="noexternaljar" description="use only company jar"/> + <conf name="withexternaljar" description="use company jar and third party jars"/> </configurations> - + <dependencies> <dependency org="org.apache" name="filter-framework" rev="latest.integration" conf="build->api; noexternaljar->homemade-impl; withexternaljar->cc-impl"/> </dependencies> @@ -133,11 +133,11 @@ We create 3 configurations that define the different ways we want to use the app We also defined a dependency on our previously built library. In this dependency, we use configuration mappings to match ours with the dependency's configurations. You can find more information about configuration mapping link:../ivyfile/configurations.html[here] - + . *build->api* : here we tell Ivy that our *build* configuration depends on the *api* configuration of the dependency + - + . *noexternaljar->homemade-impl* : here we tell Ivy that our *noexternaljar* configuration depends on the *homemade-impl* configuration of the dependency. + - + . *withexternaljar->cc-impl* : here we tell Ivy that our *withexternaljar* configuration depends on the *cc-impl* configuration of the dependency + Note that we never declare any of the dependency's artifacts we need in each configuration: it's the dependency module's ivy file which declares the published artifacts and which should be used in each configuration. @@ -148,9 +148,9 @@ In the Ant `build.xml` file, we defined a 'resolve' target as follow: [source] ---- -<target name="resolve" description="--> retreive dependencies with ivy"> +<target name="resolve" description="--> retrieve dependencies with ivy"> <ivy:retrieve pattern="${ivy.lib.dir}/[conf]/[artifact].[ext]"/> -</target> +</target> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/defaultconf.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/defaultconf.adoc b/asciidoc/tutorial/defaultconf.adoc index 52b68f0..ac0841e 100644 --- a/asciidoc/tutorial/defaultconf.adoc +++ b/asciidoc/tutorial/defaultconf.adoc @@ -17,7 +17,7 @@ under the License. //// -Ivy comes bundled with some default settings which makes it pretty simple to use in a typical environment. This tutorial, which is close to a reference document, explains what those default settings are and how they can be adjusted to your needs. +Ivy comes bundled with some default settings which makes it pretty simple to use in a typical environment. This tutorial, which is close to a reference document, explains what those default settings are and how they can be adjusted to your needs. To fully understand the concept of settings and what you can do with them, we suggest reading other tutorials related to settings (like link:../tutorial/multiple.html[Multiple Resolvers] and link:../tutorial/dual.html[Dual Resolver]) or the link:../settings.html[Settings Files] reference documentation. @@ -28,7 +28,7 @@ The default settings include 3 types of repositories: * local + - a repository which is private to the user. + a repository which is private to the user. * shared + a repository which is shared between all the members of a team @@ -45,13 +45,13 @@ Now let's describe each of these repository concepts in more detail. We will des The local repository is particularly useful when you want to do something without being disturbed by anything else happening in the environment. This means that whenever Ivy is able to locate a module in this repository it will be used, no matter what is available in others. -For instance, if you have a module declaring a dependency on the module __foo__ with a revision of __latest.integration__, then if a revision of __foo__ is found in the local repository, it will be used, _even if a more recent revision is available in other repositories_. +For instance, if you have a module declaring a dependency on the module __foo__ with a revision of __latest.integration__, then if a revision of __foo__ is found in the local repository, it will be used, _even if a more recent revision is available in other repositories_. This may be disturbing for some of you, but imagine you have to implement a new feature on a project, and in order to achieve that you need to modify two modules: you add a new method in module __foo__ and exploit this new method in module __bar__. Then if you publish the module __foo__ to your local repository, you will be sure to get it in your __bar__ module, even if someone else publishes a new revision of __foo__ in the shared repository (this revision not having the new method you are currently adding). But be careful, when you have finished your development and publish it on the shared repository, you will have to clean your local repository to benefit from new versions published in the shared repository. -Note also that modules found in the local repository must be complete, i.e. they must provide both a module descriptor and the published artifacts. +Note also that modules found in the local repository must be complete, i.e. they must provide both a module descriptor and the published artifacts. === Shared @@ -82,7 +82,7 @@ For example: <target name="resolve"> <property name="ivy.default.ivy.user.dir" value="/path/to/ivy/user/dir"/> - <ivy:resolve /> + <ivy:resolve/> </target> ---- @@ -91,7 +91,7 @@ Next we will show you how to override default values for the different kinds of === Local -By default, the local repository lies in `${ivy.default.ivy.user.dir}/local`. This is usually a good place, but you may want to modify it. No problem, you just have to set the following Ivy variable to the directory you want to use: +By default, the local repository lies in `${ivy.default.ivy.user.dir}/local`. This is usually a good place, but you may want to modify it. No problem, you just have to set the following Ivy variable to the directory you want to use: [source] ---- ivy.local.default.root @@ -135,7 +135,7 @@ ivy.local.default.artifact.pattern=[module]/[revision]/[artifact].[ext] === Shared -By default, the shared repository lies in `${ivy.default.ivy.user.dir}/shared`. This is fine if you work alone, but the shared repository is supposed to be, mmm, shared! So changing this directory is often required, and it is usually modified to point to a network shared directory. You can use the +By default, the shared repository lies in `${ivy.default.ivy.user.dir}/shared`. This is fine if you work alone, but the shared repository is supposed to be, mmm, shared! So changing this directory is often required, and it is usually modified to point to a network shared directory. You can use the [source] ---- ivy.shared.default.root @@ -172,7 +172,7 @@ ivy.shared.default.artifact.pattern=[organisation]/[module]/[revision]/[artifact By default, the public repository is ibiblio in m2 compatible mode (in other words, the maven 2 public repository). -This repository has the advantage of providing a lot of modules, with metadata for most of them. The quality of metadata is not always perfect, but it's a very good start to use a tool like Ivy and benefit from the power of transitive dependency management. +This repository has the advantage of providing a lot of modules, with metadata for most of them. The quality of metadata is not always perfect, but it's a very good start to use a tool like Ivy and benefit from the power of transitive dependency management. Despite its ease of use, we suggest reading the link:../bestpractices.html[Best practices] to have a good understanding of the pros and cons of using a public unmanaged repository before depending on such a repository for your enterprise build system. @@ -182,7 +182,7 @@ ivy.14.compatible=true as an ant property_ == Going further -OK, so we have seen how to easily change the settings of the three main repositories. But what if my shared repository is on a web server? What if you don't want to use maven 2 repository as the public repository? What if ... +OK, so we have seen how to easily change the settings of the three main repositories. But what if my shared repository is on a web server? What if you don't want to use maven 2 repository as the public repository? What if ... No problem, Ivy is very flexible and can be configured with specific settings to match your needs and environment. But before considering writing your own settings from scratch, we suggest reading the following where you will learn how to leverage a part of the default settings and adjust the rest. @@ -229,8 +229,8 @@ To finish this example, you have to write your own ivysettings file (that you wi <ivysettings> <resolvers> <filesystem name="public"> - <ivy pattern="/path/to/my/public/rep/[organisation]/[module]/ivy-[revision].xml" /> - <artifact pattern="/path/to/my/public/rep/[organisation]/[module]/[artifact]-[revision].[ext]" /> + <ivy pattern="/path/to/my/public/rep/[organisation]/[module]/ivy-[revision].xml"/> + <artifact pattern="/path/to/my/public/rep/[organisation]/[module]/[artifact]-[revision].[ext]"/> </filesystem> </resolvers> </ivysettings> @@ -262,8 +262,8 @@ Now the last thing you will need in order to properly take advantage of the defa <property name="ivy.shared.default.artifact.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/> <resolvers> <filesystem name="shared"> - <ivy pattern="${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern}" /> - <artifact pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}" /> + <ivy pattern="${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern}"/> + <artifact pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}"/> </filesystem> </resolvers> </ivysettings> @@ -281,8 +281,8 @@ Now the last thing you will need in order to properly take advantage of the defa <property name="ivy.local.default.artifact.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/> <resolvers> <filesystem name="local"> - <ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" /> - <artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" /> + <ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}"/> + <artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}"/> </filesystem> </resolvers> </ivysettings> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/dependence.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/dependence.adoc b/asciidoc/tutorial/dependence.adoc index 0fa3b8b..502cb3f 100644 --- a/asciidoc/tutorial/dependence.adoc +++ b/asciidoc/tutorial/dependence.adoc @@ -19,11 +19,11 @@ This tutorial will show you how to use Ivy when one of your projects depends on another. -For our example, we will have two projects, depender and dependee, where the depender project uses/requires the dependee project. This example will help illustrate two things about Ivy: +For our example, we will have two projects, depender and dependee, where the depender project uses/requires the dependee project. This example will help illustrate two things about Ivy: + - * that dependencies defined by parent projects (dependee) will automatically be retrieved for use by child projects (depender) + - + * that child projects can retrieve the "latest" version of the dependee project + @@ -34,19 +34,19 @@ For our example, we will have two projects, depender and dependee, where the dep The dependee project is very simple. It depends on the apache library commons-lang and contains only one class: `standalone.Main` which provides two services: - + * return the version of the project + - + * capitalize a string using `org.apache.commons.lang.WordUtils.capitalizeFully` + Here is the content of the project: - + * build.xml: the ant build file for the project + - + * ivy.xml: the project ivy file + - -* src tandalone\Main.java: the only class of the project + + +* src standalone\Main.java: the only class of the project + Take a look at the *ivy.xml* file: @@ -68,9 +68,9 @@ The ivy file declares only one dependency, that being the apache commons-lang li The depender project is very simple as well. It declares only one dependency on the latest version of the dependee project, and it contains only one class, `depending.Main`, which does 2 things: - + * gets the version of the standalone project by calling `standalone.Main.getVersion()` + - + * transforms a string by calling `standalone.Main.capitalizeWords(str)` + Take a look at the `ivy.xml` file: @@ -81,7 +81,7 @@ Take a look at the `ivy.xml` file: <ivy-module version="1.0"> <info organisation="org.apache" module="depender"/> <dependencies> - <dependency name="dependee" rev="latest.integration" /> + <dependency name="dependee" rev="latest.integration"/> </dependencies> </ivy-module> @@ -92,9 +92,9 @@ Take a look at the `ivy.xml` file: The Ivy settings are defined in two files located in the settings directory: - + * `ivysettings.properties`: a property file + - + * `ivysettings.xml`: the file containing the settings + @@ -105,14 +105,14 @@ Let's have a look at the `ivysettings.xml` file: <ivysettings> <properties file="${ivy.settings.dir}/ivysettings.properties"/> - <settings defaultResolver="libraries" /> - <caches defaultCacheDir="${ivy.settings.dir}/ivy-cache" /> + <settings defaultResolver="libraries"/> + <caches defaultCacheDir="${ivy.settings.dir}/ivy-cache"/> <resolvers> <filesystem name="projects"> - <artifact pattern="${repository.dir}/[artifact]-[revision].[ext]" /> - <ivy pattern="${repository.dir}/[module]-[revision].xml" /> + <artifact pattern="${repository.dir}/[artifact]-[revision].[ext]"/> + <ivy pattern="${repository.dir}/[module]-[revision].xml"/> </filesystem> - <ibiblio name="libraries" m2compatible="true" usepoms="false" /> + <ibiblio name="libraries" m2compatible="true" usepoms="false"/> </resolvers> <modules> <module organisation="org.apache" name="dependee" resolver="projects"/> @@ -129,13 +129,13 @@ This tag loads some properties for the Ivy process, just like Ant does. === settings -This tag initializes some parameters for the Ivy process. In this case, the directory that Ivy will use to cache artifacts will be in a sub directory called ivy-cache of the directory containing the `ivysettings.xml` file itself. +This tag initializes some parameters for the Ivy process. In this case, the directory that Ivy will use to cache artifacts will be in a sub directory called ivy-cache of the directory containing the `ivysettings.xml` file itself. The second parameter, tells Ivy to use a resolver named "libraries" as its default resolver. More information can be found in the link:../settings.html[settings reference documentation]. === resolvers This tag defines the resolvers to use. Here we have two resolvers defined: "projects" and "libraries". -The filesystem resolver called "projects" is able to resolve the internal dependencies by locating them on the local filesystem. +The filesystem resolver called "projects" is able to resolve the internal dependencies by locating them on the local filesystem. The ibiblio resolver called "libraries" is able to find dependencies on the maven 2 repository, but doesn't use maven poms. === modules @@ -175,11 +175,11 @@ include::asciidoc/tutorial/log/dependence-standalone.txt[] What we see here: - + * the project depends on 1 library (1 artifact) + - + * the library was not in the Ivy cache and so was downloaded (1 downloaded) + - + * the project has been released under version number 1 + @@ -210,13 +210,13 @@ include::asciidoc/tutorial/log/dependence-depending.txt[] What we see here: - + * the project depends on 2 libraries (2 artifacts) + - + * one of the libraries was in the cache because there was only 1 download (1 downloaded) + - + * Ivy retrieved version 1 of the project "dependee". The call to `standalone.Main.getVersion()` has returned 1. If you look in the `depender/lib` directory, you should see `dependee-1.jar` which is the version 1 artifact of the project "dependee" + - + * the call to `standalone.Main.capitalizeWords(str)` succeed, which means that the required library was in the classpath. If you look at the `lib` directory, you will see that the library `commons-lang-2.0.jar` was also retrieved. This library was declared as a dependency of the "dependee" project, so Ivy retrieves it (transitively) along with the dependee artifact. + @@ -253,11 +253,11 @@ OK, now our repository contains two versions of the project *dependee*, so other === step 6: get the new version in _depender_ project -What should we expect if we run the depender project again? It should: +What should we expect if we run the depender project again? It should: + - * retrieve version 2 as the latest.integration version of the dependee project + - + * display version 2 of dependee project + Let's try it!! http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/dual.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/dual.adoc b/asciidoc/tutorial/dual.adoc index 594676a..ba33d9c 100644 --- a/asciidoc/tutorial/dual.adoc +++ b/asciidoc/tutorial/dual.adoc @@ -43,11 +43,11 @@ It depends on two libraries: Apache commons-lang and Apache commons-httpclient. Here is the content of the project: - + * build.xml: the ant build file for the project + - + * ivy.xml: the ivy project file + - + * src\example\Hello.java: the only class of the project + @@ -82,9 +82,9 @@ The ivy settings are defined in the `ivysettings.xml` file located in the `setti <resolvers> <dual name="dual-example"> <filesystem name="ivys"> - <ivy pattern="${ivy.settings.dir}/../repository/[module]-ivy-[revision].xml" /> + <ivy pattern="${ivy.settings.dir}/../repository/[module]-ivy-[revision].xml"/> </filesystem> - <ibiblio name="ibiblio" m2compatible="true" usepoms="false" /> + <ibiblio name="ibiblio" m2compatible="true" usepoms="false"/> </dual> </resolvers> </ivysettings> @@ -136,7 +136,7 @@ As you can see, Ivy not only downloaded commons-lang and commons-httpclient, but ---- <ivy-module version="1.0"> - <info + <info organisation="commons-httpclient" module="commons-httpclient" revision="2.0.2" @@ -151,7 +151,7 @@ As you can see, Ivy not only downloaded commons-lang and commons-httpclient, but -So everything seemed to work. The ivy file was found in the `repository` directory and the artifacts have been downloaded from ibiblio. +So everything seemed to work. The ivy file was found in the `repository` directory and the artifacts have been downloaded from ibiblio. This kind of setup can be useful if you don't want to rely on the maven 2 repository for metadata, or if you want to take full advantage of Ivy files for some or all modules. Combining chain and dual resolvers should give you enough flexibility to meet almost any requirement. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/multiple.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/multiple.adoc b/asciidoc/tutorial/multiple.adoc index 328f852..e1707f3 100644 --- a/asciidoc/tutorial/multiple.adoc +++ b/asciidoc/tutorial/multiple.adoc @@ -45,11 +45,11 @@ It depends on two libraries: Apache's commons-lang and a custom library named te Here is the content of the project: - + * build.xml: the ant build file for the project + - + * ivy.xml: the Ivy project file + - + * src\example\Hello.java: the only class of the project + Let's have a look at the *ivy.xml* file: @@ -83,9 +83,9 @@ The settings are defined in the ivysettings.xml file located in the settings dir <resolvers> <chain name="chain-example"> <filesystem name="libraries"> - <artifact pattern="${ivy.settings.dir}/repository/[artifact]-[revision].[ext]" /> + <artifact pattern="${ivy.settings.dir}/repository/[artifact]-[revision].[ext]"/> </filesystem> - <ibiblio name="ibiblio" m2compatible="true" /> + <ibiblio name="ibiblio" m2compatible="true"/> </chain> </resolvers> </ivysettings> @@ -103,9 +103,9 @@ This tag initializes Ivy with some parameters. Here only one parameter is set, t The resolvers section defines the list of resolvers that Ivy will use to locate artifacts. In our example, we have only one resolver named "chain-example", which is unique in that it defines a list (hence a chain) of resolvers. The resolvers in this chain are: - + * libraries : It is a filesystem resolver, so looks at a directory structure to retrieve the artifacts. This one is configured to look in the `repository` sub directory of the directory that contains the `ivysettings.xml` file. + - + * ibiblio : It looks in the ibiblio maven repository to retrieve the artifacts. + @@ -132,7 +132,7 @@ This will clean up the entire project directory tree and Ivy cache. You can do t [NOTE] ==== -In almost all examples, we provide a clean target as default target. Since most examples use the same Ivy cache, you will clean the whole Ivy cache each time you call this target. +In almost all examples, we provide a clean target as default target. Since most examples use the same Ivy cache, you will clean the whole Ivy cache each time you call this target. Cleaning the Ivy cache is something you can do without fear (except performance): it's only a cache, so everything can be (and should be) obtained again from repositories. This may sound strange to those coming from maven 2 land. But remember that in Ivy, the cache is not a local repository and the two are completely isolated. @@ -155,7 +155,7 @@ include::asciidoc/tutorial/log/chained-resolvers.txt[] -We can see in the log of the resolve task, that the two dependencies have been retrieved (2 artifacts) and copied to the Ivy cache directory (2 downloaded). +We can see in the log of the resolve task, that the two dependencies have been retrieved (2 artifacts) and copied to the Ivy cache directory (2 downloaded). Also notice that the 'run' Ant target succeeded in using both commons-lang.jar coming from the ibiblio repository and test.jar coming from the local repository. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/multiproject.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/multiproject.adoc b/asciidoc/tutorial/multiproject.adoc index c2eee52..9877142 100644 --- a/asciidoc/tutorial/multiproject.adoc +++ b/asciidoc/tutorial/multiproject.adoc @@ -83,7 +83,7 @@ contains a directory per module, with each containing: ---- <ivy-module version="1.0"> - <info + <info organisation="org.apache.ivy.example" module="find" status="integration"/> @@ -92,13 +92,13 @@ contains a directory per module, with each containing: <conf name="standalone" extends="core"/> </configurations> <publications> - <artifact name="find" type="jar" conf="core" /> + <artifact name="find" type="jar" conf="core"/> </publications> <dependencies> - <dependency name="version" rev="latest.integration" conf="core->default" /> - <dependency name="list" rev="latest.integration" conf="core" /> - <dependency org="commons-collections" name="commons-collections" rev="3.1" conf="core->default" /> - <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="standalone->default" /> + <dependency name="version" rev="latest.integration" conf="core->default"/> + <dependency name="list" rev="latest.integration" conf="core"/> + <dependency org="commons-collections" name="commons-collections" rev="3.1" conf="core->default"/> + <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="standalone->default"/> </dependencies> </ivy-module> @@ -113,7 +113,7 @@ contains a directory per module, with each containing: <project name="find" default="compile"> <property file="build.properties"/> - + <import file="${common.dir}/common.xml"/> </project> @@ -154,7 +154,7 @@ So, here are some aspects of this common build file: <property name="ivy.shared.default.root" value="${repository.dir}/shared"/> <!-- here is how we would have configured ivy if we had our own ivysettings file -<ivy:settings file="${common.dir}/ivysettings.xml" id="ivy.instance" /> +<ivy:settings file="${common.dir}/ivysettings.xml" id="ivy.instance"/> --> ---- @@ -171,10 +171,10 @@ Commented out you can see how the settings would have been done if the default s <target name="resolve" depends="clean-lib, load-ivy" description="--> resolve and retrieve dependencies with ivy"> <mkdir dir="${lib.dir}"/> <!-- not usually necessary, ivy creates the directory IF there are dependencies --> - + <!-- the call to resolve is not mandatory, retrieve makes an implicit call if we don't --> <ivy:resolve file="${ivy.file}"/> - <ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" /> + <ivy:retrieve pattern="${lib.dir}/[artifact].[ext]"/> </target> ---- @@ -190,12 +190,12 @@ You should begin to be familiar with using Ivy this way. We call __resolve__ exp <target name="ivy-new-version" depends="load-ivy" unless="ivy.new.revision"> <!-- default module version prefix value --> - <property name="module.version.prefix" value="${module.version.target}-dev-b" /> - + <property name="module.version.prefix" value="${module.version.target}-dev-b"/> + <!-- asks Ivy for an available version number --> - <ivy:info file="${ivy.file}" /> - <ivy:buildnumber - organisation="${ivy.organisation}" module="${ivy.module}" + <ivy:info file="${ivy.file}"/> + <ivy:buildnumber + organisation="${ivy.organisation}" module="${ivy.module}" revision="${module.version.prefix}" defaultBuildNumber="1" revSep=""/> </target> @@ -211,12 +211,11 @@ This target is used to ask Ivy to find a new version for a module. To get detail ---- <target name="publish" depends="clean-build, jar" description="--> publish this project in the ivy repository"> - <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" + <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" resolver="shared" - pubrevision="${version}" - status="release" - /> - <echo message="project ${ant.project.name} released with version ${version}" /> + pubrevision="${version}" + status="release"/> + <echo message="project ${ant.project.name} released with version ${version}"/> </target> ---- @@ -230,14 +229,13 @@ This target publishes the module to the shared repository, with the revision fou ---- <target name="publish-local" depends="local-version, jar" description="--> publish this project in the local ivy repository"> - <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" + <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]" resolver="local" pubrevision="${version}" pubdate="${now}" status="integration" - forcedeliver="true" - /> - <echo message="project ${ant.project.name} published locally with version ${version}" /> + forcedeliver="true"/> + <echo message="project ${ant.project.name} published locally with version ${version}"/> </target> ---- @@ -272,7 +270,7 @@ This target is used when you don't want to use your local version of a module an Generates both an html report and a graphml report. -For example, to generate a graph like the one shown at the beginning of this tutorial, you just have to follow the instructions given link:../yed.html[here] with the graphml file you will find in +For example, to generate a graph like the one shown at the beginning of this tutorial, you just have to follow the instructions given link:../yed.html[here] with the graphml file you will find in [source] ---- projects/console/build/ http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/tutorial/start.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/tutorial/start.adoc b/asciidoc/tutorial/start.adoc index e406ffa..4471a65 100644 --- a/asciidoc/tutorial/start.adoc +++ b/asciidoc/tutorial/start.adoc @@ -17,7 +17,7 @@ under the License. //// -In this tutorial, you will see one of the simplest ways to use Ivy. With no specific settings, Ivy uses the maven 2 repository to resolve the dependencies you declare in an Ivy file. Let's have a look at the content of the files involved. +In this tutorial, you will see one of the simplest ways to use Ivy. With no specific settings, Ivy uses the maven 2 repository to resolve the dependencies you declare in an Ivy file. Let's have a look at the content of the files involved. _You'll find this tutorial's sources in the ivy distribution in the src/example/hello-ivy directory._ @@ -25,7 +25,7 @@ _You'll find this tutorial's sources in the ivy distribution in the src/example/ == The ivy.xml file This file is used to describe the dependencies of the project on other libraries. -Here is the sample: +Here is the sample: [source] ---- @@ -40,11 +40,11 @@ Here is the sample: ---- -The format of this file should pretty easy to understand, but let's give some details about what is declared here. First, the root element ivy-module, with the version attribute used to tell Ivy which version of Ivy this file uses. +The format of this file should pretty easy to understand, but let's give some details about what is declared here. First, the root element ivy-module, with the version attribute used to tell Ivy which version of Ivy this file uses. Then there is an info tag, which is used to give information about the module for which we are defining dependencies. Here we define only the organization and module name. You are free to choose whatever you want for them, but we recommend avoiding spaces for both. -Finally, the dependencies section lets you define dependencies. Here this module depends on two libraries: commons-lang and commons-cli. As you can see, we use the `org` and `name` attributes to define the organization and module name of the dependencies we need. The `rev` attribute is used to specify the version of the module you depend on. +Finally, the dependencies section lets you define dependencies. Here this module depends on two libraries: commons-lang and commons-cli. As you can see, we use the `org` and `name` attributes to define the organization and module name of the dependencies we need. The `rev` attribute is used to specify the version of the module you depend on. To know what to put in these attributes, you need to know the exact information for the libraries you depend on. Ivy uses the maven 2 repository by default, so we recommend you use link:http://mvnrepository.com[mvnrepository.com] to look for the module you want. Once you find it, you will have the details on how to declare the dependency in a maven POM. For instance: @@ -72,14 +72,14 @@ You can use the standard "ant -p" to get the list of available targets. Feel fre ---- <project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run"> - + ... - - <!-- ================================= - target: resolve + + <!-- ================================= + target: resolve ================================= --> <target name="resolve" description="--> retrieve dependencies with ivy"> - <ivy:retrieve /> + <ivy:retrieve/> </target> </project> @@ -107,7 +107,7 @@ include::asciidoc/tutorial/log/hello-ivy-1.txt[] == What happened ? -Without any settings, Ivy retrieves files from the maven 2 repository. That's what happened here. +Without any settings, Ivy retrieves files from the maven 2 repository. That's what happened here. The resolve task has found the commons-lang and commons-cli modules in the maven 2 repository, identified that commons-cli depends on commons-logging and so resolved it as a transitive dependency. Then Ivy has downloaded all corresponding artifacts in its cache (by default in your user home, in a .ivy2/cache directory). Finally, the retrieve task copies the resolved jars from the ivy cache to the default library directory of the project: the lib dir (you can change this easily by setting the pattern attribute on the link:../use/retrieve.html[retrieve] task). You might say that the task took a long time just to write out a "Hello Ivy!" message. But remember that a lot of time was spent downloading the required files from the web. Let's try to run it again: http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/artifactproperty.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/artifactproperty.adoc b/asciidoc/use/artifactproperty.adoc index a962f82..dd24317 100644 --- a/asciidoc/use/artifactproperty.adoc +++ b/asciidoc/use/artifactproperty.adoc @@ -52,7 +52,7 @@ Then: [source,xml] ---- <artifactproperty conf="build" - name="[module].[artifact]-[revision]" + name="[module].[artifact]-[revision]" value="${cache.dir}/[module]/[artifact]-[revision].[ext]"/> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/artifactreport.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/artifactreport.adoc b/asciidoc/use/artifactreport.adoc index 6051e78..64048d8 100644 --- a/asciidoc/use/artifactreport.adoc +++ b/asciidoc/use/artifactreport.adoc @@ -22,7 +22,7 @@ The `artifactreport` task generates an xml report of all artifacts dependencies *__since 2.0__* This is a link:../use/postresolvetask.html[post resolve task], with all the behaviour and attributes common to all post resolve tasks. -This report is different from the standard link:../use/report.html[report] which reports all modules and artifacts, whle this report is much simpler and focuses only on artifacts, and gives more information on artifacts, such as the original location and the retrieve location. +This report is different from the standard link:../use/report.html[report] which reports all modules and artifacts, while this report is much simpler and focuses only on artifacts, and gives more information on artifacts, such as the original location and the retrieve location. It is thus easy to use to generate things like a classpath file for an IDE. @@ -76,7 +76,7 @@ Here is an example of generate file: [source,xml] ---- -<ivy:artifactreport tofile="${basedir}/path/to/myreport.xml" /> +<ivy:artifactreport tofile="${basedir}/path/to/myreport.xml"/> ---- Generates the artifact report for all configurations resolved during the last resolve call (in the same build). http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/buildlist.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/buildlist.adoc b/asciidoc/use/buildlist.adoc index 54a4055..45f47ab 100644 --- a/asciidoc/use/buildlist.adoc +++ b/asciidoc/use/buildlist.adoc @@ -19,7 +19,7 @@ The `buildlist` task enable to obtain a `filelist` of files (usually `build.xml` files) ordered according to Ivy dependency information from the least dependent to the most one, or the inverse. (*__since 1.2__*) -This is particularly useful combined with `subant`, to build a set of interelated projects being sure that a dependency will be built before any module depending on it. +This is particularly useful combined with `subant`, to build a set of interrelated projects being sure that a dependency will be built before any module depending on it. When the `ivy.xml` of the modules that you want to order doesn't contains a link:../ivyfile/info.html[revision] numbers, the `rev` attributes declared in the dependency is not used. When the `ivy.xml` of the modules that you want to order contains a link:../ivyfile/info.html[revision] numbers, the revision numbers are used. If the revision number doesn't match a dependency description a warning is logged and the modules is considered as different modules. @@ -32,7 +32,7 @@ When the `ivy.xml` of the modules that you want to order contains a link:../ivyf *__since 2.0__* The `root` and `leaf` attributes can be a delimited list of modules to use as roots. These modules, and all their dependencies will be included in the build list. -*__since 2.0__* By default, all the modules included in a circular dependency are grouped together so that any dependency of any module in the loop will apear before the modules in the loop. This garantee that if there is a depedendency path between a module A and a module B (but no dependency path from B to A), B will alway apear before A even if A is included in a loop in the provided set of modules to sort. +*__since 2.0__* By default, all the modules included in a circular dependency are grouped together so that any dependency of any module in the loop will appear before the modules in the loop. This guarantee that if there is a dependency path between a module A and a module B (but no dependency path from B to A), B will always appear before A even if A is included in a loop in the provided set of modules to sort. Note that circular dependency can also trigger a failure depending on the value configured in the `circularDependencyStrategy` of your link:../settings/conf.html#circularDependencyStrategy[settings] *__since 2.0__* When you are specifying `root` or `leaf` modules you can limit the resulting list to only direct dependencies of the roots modules or to modules that directly depends on your leaf modules. @@ -50,7 +50,7 @@ Note that circular dependency can also trigger a failure depending on the value *__since 1.3__* Was limited to only one module name before 2.0.|No. Defaults to no root (all modules are used in the build list) |excluderoot|*__since 1.3__* `true` if the root defined should be excluded from the list|No. Defaults to `false` -|leaf|*__since 2.0__* the names of the modules which should be considered as the leaf of the buildlist. +|leaf|*__since 2.0__* the names of the modules which should be considered as the leaf of the buildlist. *__since 1.4.1__* Was limited to only one module name before 2.0.|No. Defaults to no leaf (all modules are used in the build list) |onlydirectdep|*__since 2.0__* `true` if the resulting list should be restricted to direct dependencies of root modules or modules that directly depends on the leaf modules. @@ -69,7 +69,7 @@ This field is ignored when neither root neither leaf is filled. * `fail`: halt the build with a failure. |No. Defaults to `head` |reverse|`true` to obtain the list in the reverse order, i.e. from the most dependent to the least one|No. Defaults to default `false` -|restartFrom|*__since 2.0__* The name of the module which should be considered as the starting point in the buildlist. This allows for the build to be started at any point in the dependency chain. +|restartFrom|*__since 2.0__* The name of the module which should be considered as the starting point in the buildlist. This allows for the build to be started at any point in the dependency chain. |No. Defaults to `*` meaning no restart point (all modules are used in the build list). |settingsRef|*__since 2.0__* A reference to the ivy settings that must be used by this task|No, `ivy.instance` is taken by default. |======= @@ -95,7 +95,7 @@ This list can then be used like that: [source,xml] ---- - <subant target="build" buildpathref="build-path" /> + <subant target="build" buildpathref="build-path"/> ---- ''' http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/buildnumber.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/buildnumber.adoc b/asciidoc/use/buildnumber.adoc index 5270470..6560f9e 100644 --- a/asciidoc/use/buildnumber.adoc +++ b/asciidoc/use/buildnumber.adoc @@ -75,7 +75,7 @@ Here is how it can be used (suppose 1.3.1 is the latest version of ivy in the re [source,xml] ---- -<ivy:buildnumber organisation="apache" module="ivy" /> +<ivy:buildnumber organisation="apache" module="ivy"/> ---- will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as new build number @@ -84,7 +84,7 @@ will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as ne [source,xml] ---- -<ivy:buildnumber organisation="apache" module="ivy" revision="1.3" /> +<ivy:buildnumber organisation="apache" module="ivy" revision="1.3"/> ---- will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as new build number @@ -93,7 +93,7 @@ will set 1.3.1 as revision, 1.3.2 as new revision, 1 as build number and 2 as ne [source,xml] ---- -<ivy:buildnumber organisation="apache" module="ivy" revision="1.2" /> +<ivy:buildnumber organisation="apache" module="ivy" revision="1.2"/> ---- will set 1.2 as revision, 1.2.1 as new revision, no build number and 1 as new build number @@ -102,7 +102,7 @@ will set 1.2 as revision, 1.2.1 as new revision, no build number and 1 as new bu [source,xml] ---- -<ivy:buildnumber organisation="apache" module="ivy" revision="1." /> +<ivy:buildnumber organisation="apache" module="ivy" revision="1."/> ---- will set 1.3.1 as revision, 1.4 as new revision, 3 as build number and 4 as new build number @@ -111,7 +111,7 @@ will set 1.3.1 as revision, 1.4 as new revision, 3 as build number and 4 as new [source,xml] ---- -<ivy:buildnumber organisation="apache" module="ivy" revision="3." /> +<ivy:buildnumber organisation="apache" module="ivy" revision="3."/> ---- will set no revision, 3.0 as new revision, no build number and 0 as new build number http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/buildobr.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/buildobr.adoc b/asciidoc/use/buildobr.adoc index ce746a0..cdc0fd5 100644 --- a/asciidoc/use/buildobr.adoc +++ b/asciidoc/use/buildobr.adoc @@ -26,7 +26,7 @@ The set of jars which will be described by the OBR can be defined in 4 exclusive * 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] -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 files or artifacts, only the actually OSGi bundles will be described by the OBR descriptor; the other files are ignored. == Attributes @@ -42,14 +42,14 @@ NB: among every listed files or artifacts, only the actually OSGi bundles will b |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 illformed|No. Defaults to `false` +|quiet|Log as debug rather than warning the rejected jars as they are ill-formed|No. Defaults to `false` |======= == Examples [source,xml] ---- - <ivy:buildobr baseDir="${eclipse.home}" out="${basedir}/target/repo-eclipse.xml" indent="true" /> + <ivy:buildobr baseDir="${eclipse.home}" out="${basedir}/target/repo-eclipse.xml" indent="true"/> ---- Builds an indented OBR descriptor from an Eclipse install, with their path relative to the Eclipse install. @@ -58,8 +58,8 @@ Builds an indented OBR descriptor from an Eclipse install, with their path relat [source,xml] ---- - <ivy:configure file="ivysettings.xml" /> - <ivy:buildobr resolverName="my-file-resolver" out="${basedir}/target/repo-eclipse.xml" /> + <ivy:configure file="ivysettings.xml"/> + <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. @@ -68,8 +68,8 @@ Configure an Ivy settings and builds an OBR descriptor from jars resolved by the [source,xml] ---- - <ivy:configure file="ivysettings.xml" /> - <ivy:buildobr cacheName="my-cache" out="${basedir}/target/repo-eclipse.xml" /> + <ivy:configure file="ivysettings.xml"/> + <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. @@ -78,9 +78,9 @@ Configure an Ivy settings and builds an OBR descriptor from jars contained in th [source,xml] ---- - <ivy:configure file="ivysettings.xml" /> - <ivy:resolve file="ivy.xml" /> - <ivy:buildobr out="${basedir}/target-platform-obr.xml" /> + <ivy:configure file="ivysettings.xml"/> + <ivy:resolve file="ivy.xml"/> + <ivy:buildobr out="${basedir}/target-platform-obr.xml"/> ---- Launch a resolve and then build an obr.xml describing the resolved artifacts. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/cachefileset.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cachefileset.adoc b/asciidoc/use/cachefileset.adoc index 2902ab9..0e5b0af 100644 --- a/asciidoc/use/cachefileset.adoc +++ b/asciidoc/use/cachefileset.adoc @@ -20,7 +20,7 @@ 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 direcly in Ivy's cache. +does not rely on retrieve, because 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 more independent from Ivy (once artifacts are properly retrieved, Ivy is not required any more). http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/cachepath.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cachepath.adoc b/asciidoc/use/cachepath.adoc index 9903993..0cc66ee 100644 --- a/asciidoc/use/cachepath.adoc +++ b/asciidoc/use/cachepath.adoc @@ -40,7 +40,7 @@ Built path is registered in ant with a given id, and can thus be used like any o [source,xml] ---- -<cachepath pathid="default.classpath" conf="default" /> +<cachepath pathid="default.classpath" conf="default"/> ---- Construct an Ant path composed of all artifacts being part of the default configuration obtained through the last resolve call. @@ -49,7 +49,7 @@ Construct an Ant path composed of all artifacts being part of the default config [source,xml] ---- -<cachepath pathid="default.classpath" conf="default" useOrigin="true" /> +<cachepath pathid="default.classpath" conf="default" useOrigin="true"/> ---- Same as before but will use the original location for local artifacts, and the cache location for other artifacts. @@ -59,7 +59,7 @@ Same as before but will use the original location for local artifacts, and the c [source,xml] ---- <ivy:cachepath organisation="emma" module="emma" revision="2.0.4217" inline="true" conf="ant" pathid="emma.classpath"/> -<taskdef resource="emma_ant.properties" classpathref="emma.classpath" /> +<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. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/checkdepsupdate.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/checkdepsupdate.adoc b/asciidoc/use/checkdepsupdate.adoc index f418fab..bb7bafb 100644 --- a/asciidoc/use/checkdepsupdate.adoc +++ b/asciidoc/use/checkdepsupdate.adoc @@ -43,7 +43,7 @@ Then: [source,xml] ---- -<checkdepsupdate /> +<checkdepsupdate/> ---- will display the following updates in the console: @@ -59,7 +59,7 @@ Same example with transitive dependencies : [source,xml] ---- -<checkdepsupdate showTransitive="true" /> +<checkdepsupdate showTransitive="true"/> ---- will display the following updates in the console: http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/cleancache.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/cleancache.adoc b/asciidoc/use/cleancache.adoc index cca9fdb..473ca9a 100644 --- a/asciidoc/use/cleancache.adoc +++ b/asciidoc/use/cleancache.adoc @@ -24,10 +24,10 @@ This task is roughly equivalent to: [source,xml] ---- -<delete dir="${ivy.cache.dir}" /> +<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 an Ivy settings to be loaded, and settings scoping is possible only by using 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`. @@ -43,7 +43,7 @@ This task loads the Ivy settings as any other post settings task, and allows eas [source,xml] ---- -<ivy:cleancache /> +<ivy:cleancache/> ---- Cleans the cache directory as defined in the loaded settings (by default `~/.ivy2/cache`) http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/configure.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/configure.adoc b/asciidoc/use/configure.adoc index 1413ac5..cdcbeb0 100644 --- a/asciidoc/use/configure.adoc +++ b/asciidoc/use/configure.adoc @@ -30,7 +30,7 @@ See link:../settings.html[Settings Files] for details about the settings file it [options="header",cols="15%,50%,35%"] |======= |Attribute|Description|Required -|settingsId|The settings id useable in the `settingsRef` attributes of the Ivy task that needs a setting.|No, defaults to `ivy.instance` +|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 @@ -58,7 +58,7 @@ It's also possible to configure authentication settings for multiple urls. This [source,xml] ---- -<ivy:configure /> +<ivy:configure/> ---- Use either `${ivy.settings.file}` if it exists, or the link:../samples/ivysettings-default.xml[default settings file] @@ -67,22 +67,22 @@ Use either `${ivy.settings.file}` if it exists, or the link:../samples/ivysettin [source,xml] ---- -<ivy:configure file="myconffile.xml" /> +<ivy:configure file="myconffile.xml"/> ---- === Configure with an url [source,xml] ---- -<ivy:configure url="http://mysite.com/myconffile.xml"; /> +<ivy:configure url="http://mysite.com/myconffile.xml"/> ---- -=== Configure multiple URLs which require autentication +=== Configure multiple URLs which require authentication [source,xml] ---- <ivy:configure file="path/to/my/ivysettings.xml"> - <credentials host="myhost.com" realm="My Realm" username="myuser" passwd="mypasswd" /> - <credentials host="yourhost.com" realm="Your Realm" username="myuser" passwd="myotherpasswd" /> -</ivy:configure> + <credentials host="myhost.com" realm="My Realm" username="myuser" passwd="mypasswd"/> + <credentials host="yourhost.com" realm="Your Realm" username="myuser" passwd="myotherpasswd"/> +</ivy:configure> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/convertmanifest.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/convertmanifest.adoc b/asciidoc/use/convertmanifest.adoc index 29d8a27..00f3219 100644 --- a/asciidoc/use/convertmanifest.adoc +++ b/asciidoc/use/convertmanifest.adoc @@ -32,7 +32,7 @@ [source,xml] ---- - <ivy:convertmanifest manifest="META-INF/MANIFEST.MF" ivyFile="ivy.xml" /> + <ivy:convertmanifest manifest="META-INF/MANIFEST.MF" ivyFile="ivy.xml"/> ---- Just converts a manifest into an `ivy.xml` file. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/convertpom.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/convertpom.adoc b/asciidoc/use/convertpom.adoc index 5204317..b593584 100644 --- a/asciidoc/use/convertpom.adoc +++ b/asciidoc/use/convertpom.adoc @@ -32,7 +32,7 @@ [source,xml] ---- - <ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml" /> + <ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml"/> ---- Just convert an pom.xml file into an ivy.xml. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/deliver.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/deliver.adoc b/asciidoc/use/deliver.adoc index 6bb38c1..da473e1 100644 --- a/asciidoc/use/deliver.adoc +++ b/asciidoc/use/deliver.adoc @@ -35,12 +35,12 @@ Finally, in the resolved ivy file, dynamic revisions are replaced by the static This is done only if a deliver target is given to the deliver task. -If a deliver target is set, then it is called (via an `antcall`) for each dependency which has not a suffisant status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done. +If a deliver target is set, then it is called (via an `antcall`) for each dependency which has not a sufficient status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done. -If you deliver a milestone or a release revision, deliver target will be called with each integration dependency. +If you deliver a milestone or a release revision, deliver target will be called with each integration dependency. The deliver target is called with the following properties available: - + * `dependency.name`: the name of the dependency to recursively deliver * `dependency.published.status`: the status to which the dependency should be delivered * `dependency.published.version`: the revision to which the dependency should be delivered @@ -57,7 +57,7 @@ The delivered ivy file will update its dependency revisions with those given her == 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 explictly? 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. +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, ...). @@ -87,7 +87,7 @@ It can also be useful if you want to trigger a recursive delivery and then ensur |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`. |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 deliverd 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.0)__*|No. Defaults to `true` |======= == Example @@ -96,5 +96,5 @@ Deliver an ivy file without the private configurations: [source,xml] ---- -<deliver conf="*(public)" /> +<deliver conf="*(public)"/> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/dependencytree.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/dependencytree.adoc b/asciidoc/use/dependencytree.adoc index 99493d3..a036564 100644 --- a/asciidoc/use/dependencytree.adoc +++ b/asciidoc/use/dependencytree.adoc @@ -45,7 +45,7 @@ Then: [source,xml] ---- -<dependencytree /> +<dependencytree/> ---- will display the following tree in the console: http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/fixdeps.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/fixdeps.adoc b/asciidoc/use/fixdeps.adoc index 51c553a..ebf3282 100644 --- a/asciidoc/use/fixdeps.adoc +++ b/asciidoc/use/fixdeps.adoc @@ -20,7 +20,7 @@ *__since 2.4__* The `fixdeps` task serializes transitively resolved dependencies into an `ivy.xml` file. -The dependencies declared in an `ivy.xml` can be specified as range of revisions. And the transitive dependencies too. As new versions of modules can be added to the repository anytime, resolved versions of ranges can change over time. It is then safer to resolve a range once and stick with the resolved revision. This way a resolve process is highly reproductible. +The dependencies declared in an `ivy.xml` can be specified as range of revisions. And the transitive dependencies too. As new versions of modules can be added to the repository anytime, resolved versions of ranges can change over time. It is then safer to resolve a range once and stick with the resolved revision. This way a resolve process is highly reproducible. It is especially useful in a very dynamic environment like the link:../osgi.html[OSGi] one. @@ -48,7 +48,7 @@ This is a link:../use/postresolvetask.html[post resolve task], with all the beha |======= |Element|Description|Cardinality |keep|declares a dependency to keep from being fixed, and keep its original declaration from the original ivy.xml - + These elements takes two attributes: + * `org`: the organization + * `module`: the name of the module|0..n @@ -58,7 +58,7 @@ These elements takes two attributes: + [source,xml] ---- -<ivy:fixdeps tofile="ivy-fixed.xml" /> +<ivy:fixdeps tofile="ivy-fixed.xml"/> ---- Simple fix of some dependencies. @@ -68,7 +68,7 @@ Simple fix of some dependencies. [source,xml] ---- <ivy:fixdeps tofile="ivy-fixed.xml"> - <keep org="com.acme" module="mymodule" /> + <keep org="com.acme" module="mymodule"/> </ivy:fixdeps> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/info.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/info.adoc b/asciidoc/use/info.adoc index 385c1e5..40c30bc 100644 --- a/asciidoc/use/info.adoc +++ b/asciidoc/use/info.adoc @@ -89,8 +89,8 @@ Given this `ivy.xml` file: e:myextraatt="myvalue" /> <configurations> - <conf name="default" /> - <conf name="test" /> + <conf name="default"/> + <conf name="test"/> <conf name="private" visibility="private"/> </configurations> <publications> @@ -105,7 +105,7 @@ Given this `ivy.xml` file: [source,xml] ---- -<ivy:info file="${basedir}/path/to/ivy.xml" /> +<ivy:info file="${basedir}/path/to/ivy.xml"/> ---- Parses `+++${basedir}/path/to/ivy.xml+++` and set properties as described above accordingly: @@ -136,7 +136,7 @@ Given the same ivy module in a repository: [source,xml] ---- -<ivy:info organisation="apache" module="info-all" revision="1.0" /> +<ivy:info organisation="apache" module="info-all" revision="1.0"/> ---- will set the exact same set of properties as above. Using: http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/makepom.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/makepom.adoc b/asciidoc/use/makepom.adoc index 1a03e37..ddf0a21 100644 --- a/asciidoc/use/makepom.adoc +++ b/asciidoc/use/makepom.adoc @@ -28,14 +28,14 @@ _Note that all Ivy features are not supported by maven poms, so the converted po 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 containg the string `SKIP_LINE` are skipped. +* 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 `ivy:makepom` task defines following properties that can be used in the template. * `ivy.pom.groupId`: defaults to the organisation as defined in the ivy.xml file -* `ivy.pom.artifactId`: defaults to the value of the `atifactName` attribute of this task, or the name of the module as defined in the ivy.xml file -* `ivy.pom.packaging`: defaults to the value of the `artifactPackaging` attribute of this task, or the extenstion of the artifact +* `ivy.pom.artifactId`: defaults to the value of the `artifactName` attribute of this task, or the name of the module as defined in the ivy.xml file +* `ivy.pom.packaging`: defaults to the value of the `artifactPackaging` attribute of this task, or the extension of the artifact * `ivy.pom.version`: defaults to the revision as defined in the ivy.xml file * `ivy.pom.name`: defaults to `SKIP_LINE` * `ivy.pom.description`: defaults to the value of the `description` attribute of this task, or `SKIP_LINE` when not specified + http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/postresolvetask.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/postresolvetask.adoc b/asciidoc/use/postresolvetask.adoc index 232b969..f4ae1ad 100644 --- a/asciidoc/use/postresolvetask.adoc +++ b/asciidoc/use/postresolvetask.adoc @@ -54,7 +54,7 @@ The attributes listed are then mostly used only if a resolve is triggered automa |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`. |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 resuse the results of this resolve!|No. defaults to `false` for an inline resolve and to `true` in any other case +|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) |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` @@ -91,7 +91,7 @@ There is one important difference with the ivy.xml's link:../ivyfile/dependencie [source,xml] ---- <ivy:cachepath organisation="emma" module="emma" revision="2.0.4217" inline="true" conf="ant" pathid="emma.classpath"/> -<taskdef resource="emma_ant.properties" classpathref="emma.classpath" /> +<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. http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/publish.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/publish.adoc b/asciidoc/use/publish.adoc index 61f27dc..7f61f26 100644 --- a/asciidoc/use/publish.adoc +++ b/asciidoc/use/publish.adoc @@ -75,8 +75,8 @@ The source artifact pattern can be specified either as an attribute on the task [source,xml] ---- <ivy:publish resolver="local" pubrevision="1.0"> - <artifacts pattern="build/artifacts/jars/[artifact].[ext]" /> - <artifacts pattern="build/artifacts/zips/[artifact].[ext]" /> + <artifacts pattern="build/artifacts/jars/[artifact].[ext]"/> + <artifacts pattern="build/artifacts/zips/[artifact].[ext]"/> </ivy:publish> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/report.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/report.adoc b/asciidoc/use/report.adoc index fe16ee6..9a64f6f 100644 --- a/asciidoc/use/report.adoc +++ b/asciidoc/use/report.adoc @@ -54,7 +54,7 @@ To generate a HTML and graphml report: [source,xml] ---- -<report conf="compile" /> +<report conf="compile"/> ---- ''' @@ -63,7 +63,7 @@ To generate a HTML report only: [source,xml] ---- -<report conf="compile" graph="false" /> +<report conf="compile" graph="false"/> ---- ''' @@ -72,7 +72,7 @@ To generate an XML report using a custom stylesheet: [source,xml] ---- -<report conf="compile" xslfile="my-custom-stylesheet.xsl" xslext="xml" /> +<report conf="compile" xslfile="my-custom-stylesheet.xsl" xslext="xml"/> ---- To generate an XML report using a custom stylesheet which needs some parameters: @@ -80,7 +80,7 @@ To generate an XML report using a custom stylesheet which needs some parameters: [source,xml] ---- <report conf="compile" xslfile="my-custom-stylesheet.xsl" xslext="xml"> - <param name="param1" expression="value1" /> - <param name="param2" expression="value2" /> + <param name="param1" expression="value1"/> + <param name="param2" expression="value2"/> </report> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/repreport.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/repreport.adoc b/asciidoc/use/repreport.adoc index b29e43a..1668dc8 100644 --- a/asciidoc/use/repreport.adoc +++ b/asciidoc/use/repreport.adoc @@ -56,7 +56,7 @@ To generate a xml report for all the latest versions of all the modules in your [source,xml] ---- -<ivy:repreport /> +<ivy:repreport/> ---- ''' @@ -65,7 +65,7 @@ To generate a graphml report for all the latest versions of all the modules in y [source,xml] ---- -<ivy:repreport xml="false" graph="true" /> +<ivy:repreport xml="false" graph="true"/> ---- ''' @@ -74,7 +74,7 @@ To generate a xml report for all the latest versions of the modules from the org [source,xml] ---- -<ivy:repreport organisation="foo" /> +<ivy:repreport organisation="foo"/> ---- ''' @@ -83,7 +83,7 @@ To generate a xml report for all the versions on the 1.x stream of the modules n [source,xml] ---- -<ivy:repreport organisation="foo" module="bar*" revision="1.+" matcher="glob" /> +<ivy:repreport organisation="foo" module="bar*" revision="1.+" matcher="glob"/> ---- ''' @@ -92,7 +92,7 @@ To generate an XML report using a custom stylesheet: [source,xml] ---- -<ivy:repreport xsl="true" xslfile="my-custom-stylesheet.xsl" xslext="xml" /> +<ivy:repreport xsl="true" xslfile="my-custom-stylesheet.xsl" xslext="xml"/> ---- ''' @@ -102,7 +102,7 @@ To generate an XML report using a custom stylesheet which needs some parameters: [source,xml] ---- <ivy:repreport xsl="true" xslfile="my-custom-stylesheet.xsl" xslext="xml"> - <param name="param1" expression="value1" /> - <param name="param2" expression="value2" /> + <param name="param1" expression="value1"/> + <param name="param2" expression="value2"/> </report> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/resolve.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/resolve.adoc b/asciidoc/use/resolve.adoc index 4e3d9f3..371d2c4 100644 --- a/asciidoc/use/resolve.adoc +++ b/asciidoc/use/resolve.adoc @@ -110,7 +110,7 @@ __Note for developers__: after the call to this task, a reference to the module |refresh|`true` to force Ivy to resolve dynamic revision in this resolve process, `false` to use cached resolved revision *__since 2.0__*|No. defaults to `false` |resolveMode|the resolve mode to use for this dependency resolution process *__since 2.0__*|No. defaults to using the resolve mode set in the link:../settings.html[settings] |inline|`true` to use inline mode, false to resolve an ivy file *__since 1.4__*|No. defaults to `false` -|keep|`true` to keep the results of the 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 resuse the results of this resolve!|No. defaults to `false` for an inline resolve and to `true` in any other case +|keep|`true` to keep the results of the 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 |organisation|the organisation of the module to resolve in inline mode *__since 1.4__*|Yes in inline mode, no otherwise. |module|the name of the module to resolve in inline mode *__since 1.4__*|Yes in inline mode, no otherwise. |revision|the revision constraint to apply to the module to resolve in inline mode *__since 1.4__*|No. Defaults to `latest.integration` in inline mode, nothing in standard mode. @@ -164,7 +164,7 @@ Resolve all dependencies declared in path/to/ivy.xml file. [source,xml] ---- -<ivy:resolve file="path/to/ivy.xml" transitive="false" /> +<ivy:resolve file="path/to/ivy.xml" transitive="false"/> ---- Same as above, but with transitive dependencies disabled. @@ -191,7 +191,7 @@ Resolve all dependencies declared in `path/to/ivy.xml` file, but download only ` [source,xml] ---- -<ivy:resolve organisation="apache" module="commons-lang" revision="2+" inline="true" /> +<ivy:resolve organisation="apache" module="commons-lang" revision="2+" inline="true"/> ---- Resolve the `commons-lang` module revision 2+ from the repository, with its dependencies. @@ -201,9 +201,9 @@ Resolve the `commons-lang` module revision 2+ from the repository, with its depe [source,xml] ---- <ivy:resolve> - <dependency org="apache" name="commons-lang" rev="2+" /> - <dependency org="apache" name="commons-logging" rev="1.1" /> - <exclude org="apache" module="log4j" /> + <dependency org="apache" name="commons-lang" rev="2+"/> + <dependency org="apache" name="commons-logging" rev="1.1"/> + <exclude org="apache" module="log4j"/> </ivy:resolve> ---- @@ -214,7 +214,7 @@ Resolve of both `commons-lang` and `commons-logging`, with their dependencies bu [source,xml] ---- <ivy:resolve> - <dependency org="org.slf4j" module="slf4j" rev="1.6" conf="api,log4j" /> + <dependency org="org.slf4j" module="slf4j" rev="1.6" conf="api,log4j"/> </ivy:resolve> ---- http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/use/resources.adoc ---------------------------------------------------------------------- diff --git a/asciidoc/use/resources.adoc b/asciidoc/use/resources.adoc index 96fc53b..a2181e9 100644 --- a/asciidoc/use/resources.adoc +++ b/asciidoc/use/resources.adoc @@ -35,7 +35,7 @@ Build a resource collection of every artifacts of all dependencies declared in ` [source,xml] ---- -<ivy:resources file="path/to/ivy.xml" transitive="false" /> +<ivy:resources file="path/to/ivy.xml" transitive="false"/> ---- Same as above, but with transitive dependencies disabled. @@ -62,7 +62,7 @@ Build a resource collection of every `jar` artifact of all dependencies declared [source,xml] ---- -<ivy:resources organisation="apache" module="commons-lang" revision="2+" inline="true" /> +<ivy:resources organisation="apache" module="commons-lang" revision="2+" inline="true"/> ---- Build a resource collection of every artifacts of `commons-lang` module revision 2+ from the repository, with its dependencies. @@ -72,9 +72,9 @@ Build a resource collection of every artifacts of `commons-lang` module revision [source,xml] ---- <ivy:resources> - <dependency org="apache" module="commons-lang" rev="2+" /> - <dependency org="apache" module="commons-logging" rev="1.1" /> - <exclude org="apache" module="log4j" /> + <dependency org="apache" module="commons-lang" rev="2+"/> + <dependency org="apache" module="commons-logging" rev="1.1"/> + <exclude org="apache" module="log4j"/> </ivy:resources> ---- @@ -85,7 +85,7 @@ Build a resource collection of every artifacts of both `commons-lang` and `commo [source,xml] ---- <ivy:resources> - <dependency org="org.slf4j" module="slf4j" rev="1.6" conf="api,log4j" /> + <dependency org="org.slf4j" module="slf4j" rev="1.6" conf="api,log4j"/> </ivy:resources> ----
