You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by hi...@apache.org on 2017/07/02 14:57:28 UTC
[5/6] ant-ivy git commit: Check spelling; fix whitespace and links;
sort entries in .gitignore
Check spelling; fix whitespace and links; sort entries in .gitignore
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/b02336b7
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/b02336b7
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/b02336b7
Branch: refs/heads/master
Commit: b02336b76a5782e1252549b622a4593e145dfc6d
Parents: 7e764a3
Author: twogee <g....@gmail.com>
Authored: Thu Jun 29 10:46:12 2017 +0200
Committer: twogee <g....@gmail.com>
Committed: Sun Jul 2 08:05:37 2017 +0200
----------------------------------------------------------------------
.gitignore | 19 +-
asciidoc/ant.adoc | 40 +--
asciidoc/bestpractices.adoc | 18 +-
asciidoc/compatibility.adoc | 3 +-
asciidoc/concept.adoc | 54 ++--
asciidoc/configuration/caches/cache.adoc | 2 +-
asciidoc/configuration/caches/ttl.adoc | 2 +-
asciidoc/configuration/macrodef/attribute.adoc | 2 +-
asciidoc/configuration/namespace/dest.adoc | 2 +-
asciidoc/dev.adoc | 6 +-
asciidoc/dev/makerelease.adoc | 16 +-
asciidoc/index.adoc | 21 +-
asciidoc/install.adoc | 18 +-
asciidoc/ivyfile.adoc | 8 +-
asciidoc/ivyfile/artifact-conf.adoc | 2 +-
asciidoc/ivyfile/artifact-exclude.adoc | 4 +-
asciidoc/ivyfile/artifact.adoc | 10 +-
asciidoc/ivyfile/conf.adoc | 15 +-
asciidoc/ivyfile/configurations.adoc | 10 +-
asciidoc/ivyfile/conflict.adoc | 2 +-
asciidoc/ivyfile/conflicts.adoc | 8 +-
asciidoc/ivyfile/dependencies.adoc | 2 +-
asciidoc/ivyfile/dependency-artifact.adoc | 4 +-
asciidoc/ivyfile/dependency-conf.adoc | 2 +-
asciidoc/ivyfile/dependency-include.adoc | 2 +-
asciidoc/ivyfile/dependency.adoc | 16 +-
asciidoc/ivyfile/exclude.adoc | 3 +-
asciidoc/ivyfile/include.adoc | 3 +-
asciidoc/ivyfile/info.adoc | 1 -
asciidoc/ivyfile/ivyauthor.adoc | 2 +-
asciidoc/ivyfile/manager.adoc | 6 +-
asciidoc/ivyfile/mapped.adoc | 2 +-
asciidoc/ivyfile/override.adoc | 4 +-
asciidoc/moreexamples.adoc | 2 -
asciidoc/osgi.adoc | 13 +-
asciidoc/osgi/eclipse-plugin.adoc | 10 +-
asciidoc/osgi/osgi-mapping.adoc | 72 ++---
asciidoc/osgi/sigil.adoc | 1 -
asciidoc/osgi/standard-osgi.adoc | 6 +-
asciidoc/osgi/target-platform.adoc | 12 +-
asciidoc/principle.adoc | 9 +-
asciidoc/release-notes.adoc | 18 +-
asciidoc/resolver/bintray.adoc | 6 +-
asciidoc/resolver/chain.adoc | 1 -
asciidoc/resolver/dual.adoc | 2 -
asciidoc/resolver/filesystem.adoc | 4 +-
asciidoc/resolver/ibiblio.adoc | 3 +-
asciidoc/resolver/jar.adoc | 15 +-
asciidoc/resolver/mirrored.adoc | 9 +-
asciidoc/resolver/obr.adoc | 7 +-
asciidoc/resolver/osgiagg.adoc | 11 +-
asciidoc/resolver/packager.adoc | 17 +-
asciidoc/resolver/sftp.adoc | 7 +-
asciidoc/resolver/ssh.adoc | 4 +-
asciidoc/resolver/updatesite.adoc | 4 +-
asciidoc/resolver/url.adoc | 6 +-
asciidoc/resolver/vfs.adoc | 7 +-
asciidoc/running.adoc | 2 +-
asciidoc/samples/apache-hello-ivy-default.html | 14 +-
asciidoc/samples/build-install.xml | 22 +-
asciidoc/samples/build.xml | 104 +++---
asciidoc/samples/eclipse-plugin/build.xml | 38 +--
asciidoc/samples/eclipse-plugin/ivy.xml | 20 +-
.../eclipse-plugin/ivysettings.properties | 4 +-
asciidoc/samples/eclipse-plugin/ivysettings.xml | 10 +-
asciidoc/samples/ivy-doc.xsl | 36 +--
asciidoc/samples/ivy-report.css | 39 ++-
asciidoc/samples/ivy-sample-xslt.xml | 16 +-
asciidoc/samples/ivy-sample.xml | 18 +-
asciidoc/samples/ivy-style.css | 12 +-
asciidoc/samples/ivysettings-default.xml | 2 +-
.../jayasoft-ivyrep-example-default.html | 14 +-
asciidoc/samples/standard-osgi/build.xml | 44 +--
asciidoc/samples/standard-osgi/ivy.xml | 8 +-
asciidoc/samples/standard-osgi/ivysettings.xml | 8 +-
.../org.apache.ivy.sample.standard-osgi.bnd | 36 +--
asciidoc/samples/target-platform/build.xml | 34 +-
asciidoc/samples/target-platform/ivy.xml | 8 +-
.../samples/target-platform/ivysettings.xml | 8 +-
asciidoc/settings.adoc | 14 +-
asciidoc/settings/caches.adoc | 6 +-
asciidoc/settings/caches/cache.adoc | 15 +-
asciidoc/settings/caches/ttl.adoc | 6 +-
asciidoc/settings/conflict-managers.adoc | 1 -
asciidoc/settings/credentials.adoc | 1 -
asciidoc/settings/include.adoc | 2 +-
asciidoc/settings/latest-strategies.adoc | 5 +-
asciidoc/settings/lock-strategies.adoc | 2 +-
asciidoc/settings/macrodef.adoc | 31 +-
asciidoc/settings/macrodef/attribute.adoc | 3 -
asciidoc/settings/module.adoc | 7 +-
asciidoc/settings/modules.adoc | 2 -
asciidoc/settings/namespace.adoc | 3 -
asciidoc/settings/namespace/dest.adoc | 1 -
asciidoc/settings/namespace/fromtosystem.adoc | 2 -
asciidoc/settings/namespace/rule.adoc | 1 -
asciidoc/settings/namespace/src.adoc | 2 -
asciidoc/settings/namespaces.adoc | 2 -
asciidoc/settings/outputters.adoc | 3 +-
asciidoc/settings/parsers.adoc | 2 -
asciidoc/settings/properties.adoc | 5 +-
asciidoc/settings/property.adoc | 6 +-
asciidoc/settings/resolvers.adoc | 9 +-
asciidoc/settings/settings.adoc | 3 +-
asciidoc/settings/signers.adoc | 4 +-
asciidoc/settings/status.adoc | 1 -
asciidoc/settings/statuses.adoc | 6 +-
asciidoc/settings/triggers.adoc | 306 +++++++++---------
asciidoc/settings/typedef.adoc | 2 -
asciidoc/settings/version-matchers.adoc | 14 +-
asciidoc/standalone.adoc | 11 +-
asciidoc/style/style.css | 320 ++++++++-----------
asciidoc/terminology.adoc | 8 +-
asciidoc/textual.adoc | 3 +-
asciidoc/tutorial.adoc | 15 +-
asciidoc/tutorial/build-repository.adoc | 4 +-
.../tutorial/build-repository/advanced.adoc | 20 +-
asciidoc/tutorial/build-repository/basic.adoc | 20 +-
asciidoc/tutorial/conf.adoc | 24 +-
asciidoc/tutorial/defaultconf.adoc | 30 +-
asciidoc/tutorial/dependence.adoc | 62 ++--
asciidoc/tutorial/dual.adoc | 14 +-
asciidoc/tutorial/multiple.adoc | 18 +-
asciidoc/tutorial/multiproject.adoc | 48 ++-
asciidoc/tutorial/start.adoc | 20 +-
asciidoc/use/artifactproperty.adoc | 2 +-
asciidoc/use/artifactreport.adoc | 4 +-
asciidoc/use/buildlist.adoc | 10 +-
asciidoc/use/buildnumber.adoc | 10 +-
asciidoc/use/buildobr.adoc | 20 +-
asciidoc/use/cachefileset.adoc | 2 +-
asciidoc/use/cachepath.adoc | 6 +-
asciidoc/use/checkdepsupdate.adoc | 4 +-
asciidoc/use/cleancache.adoc | 6 +-
asciidoc/use/configure.adoc | 16 +-
asciidoc/use/convertmanifest.adoc | 2 +-
asciidoc/use/convertpom.adoc | 2 +-
asciidoc/use/deliver.adoc | 12 +-
asciidoc/use/dependencytree.adoc | 2 +-
asciidoc/use/fixdeps.adoc | 8 +-
asciidoc/use/info.adoc | 8 +-
asciidoc/use/makepom.adoc | 6 +-
asciidoc/use/postresolvetask.adoc | 4 +-
asciidoc/use/publish.adoc | 4 +-
asciidoc/use/report.adoc | 10 +-
asciidoc/use/repreport.adoc | 14 +-
asciidoc/use/resolve.adoc | 14 +-
asciidoc/use/resources.adoc | 12 +-
asciidoc/use/retrieve.adoc | 10 +-
asciidoc/use/settings.adoc | 24 +-
asciidoc/use/var.adoc | 2 +-
asciidoc/yed.adoc | 4 +-
build-release.xml | 31 +-
build.xml | 116 ++++---
154 files changed, 1200 insertions(+), 1301 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/.gitignore
----------------------------------------------------------------------
diff --git a/.gitignore b/.gitignore
index 40f8e72..5645641 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,22 +1,21 @@
.classpath
+.DS_Store
.idea
*.iml
.ivy2
+*~
+asciidoc/tutorial/log
bin
build
doc/style/.svn
doc/xooki/.svn
+doc/samples/target-platform/bundles
+doc/samples/target-platform/cache
lib
test/jar-repos
+test/repositories/checkmodified/ivy-1.0.xml
+test/repositories/checkmodified/mod1.1-1.0.jar
+test/repositories/norevision/ivy-mod1.1.xml
+test/repositories/norevision/mod1.1.jar
test/test-repo/bundlerepo/*.jar
test/test-repo/ivyrepo/org.apache.ivy.osgi
-.DS_Store
-doc/samples/target-platform/bundles
-doc/samples/target-platform/cache
-*~
-/test/repositories/checkmodified/ivy-1.0.xml
-/test/repositories/checkmodified/mod1.1-1.0.jar
-/test/repositories/norevision/ivy-mod1.1.xml
-/test/repositories/norevision/mod1.1.jar
-asciidoc/tutorial/log
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ant.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ant.adoc b/asciidoc/ant.adoc
index 836ecc0..bbb3291 100644
--- a/asciidoc/ant.adoc
+++ b/asciidoc/ant.adoc
@@ -41,7 +41,7 @@ If you use ant *1.5.1* or superior, you have to define the tasks you use in your
<taskdef name="ivy-configure" classname="org.apache.ivy.ant.IvyConfigure"/>
<taskdef name="ivy-resolve" classname="org.apache.ivy.ant.IvyResolve"/>
<taskdef name="ivy-retrieve" classname="org.apache.ivy.ant.IvyRetrieve"/>
- <taskdef name="ivy-deliver" classname="org.apache.ivy.ant.IvyDeliver"/>
+ <taskdef name="ivy-deliver" classname="org.apache.ivy.ant.IvyDeliver"/>
<taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
----
@@ -57,7 +57,7 @@ Once your build file is ok to call ivy tasks, the simplest way to use ivy is to
[source,xml]
----
-<ivy:retrieve />
+<ivy:retrieve/>
----
This calls ivy with default values, which might be ok in several projects. In fact, it is equivalent to:
@@ -65,11 +65,11 @@ This calls ivy with default values, which might be ok in several projects. In fa
[source,xml]
----
<target name="resolve">
- <ivy:configure />
-
- <ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}" />
-
- <ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}" />
+ <ivy:configure/>
+
+ <ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}"/>
+
+ <ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}"/>
</target>
----
@@ -87,7 +87,7 @@ ivy.project.dir = ${basedir}
ivy.lib.dir = ${ivy.project.dir}/lib
ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
ivy.distrib.dir = ${ivy.project.dir}/distrib
-
+
ivy.resolver.default.check.modified = false
ivy.default.always.check.exact.revision = true
@@ -139,33 +139,33 @@ Here is a more complete example of build file using Ivy:
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="sample" default="resolve">
<target name="resolve">
- <ivy:configure file="../ivysettings.xml" />
-
- <ivy:resolve file="my-ivy.xml" conf="default, myconf" />
-
+ <ivy:configure file="../ivysettings.xml"/>
+
+ <ivy:resolve file="my-ivy.xml" conf="default, myconf"/>
+
</target>
-
+
<target name="retrieve-default" depends="resolve">
- <ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default" />
+ <ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default"/>
</target>
<target name="retrieve-myconf" depends="resolve">
- <ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf" />
+ <ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf"/>
</target>
<target name="retrieve-all" depends="resolve">
- <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" />
+ <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*"/>
</target>
<target name="deliver" depends="retrieve-all">
<ivy:deliver deliverpattern="distrib/[artifact]-[revision].[ext]"
- pubrevision="1.1b4" pubdate="20050115123254" status="milestone" />
+ pubrevision="1.1b4" pubdate="20050115123254" status="milestone"/>
</target>
<target name="publish" depends="deliver">
- <ivy:publish resolver="internal"
- artifactspattern="distrib/[artifact]-[revision].[ext]"
- pubrevision="1.1b4" />
+ <ivy:publish resolver="internal"
+ artifactspattern="distrib/[artifact]-[revision].[ext]"
+ pubrevision="1.1b4"/>
</target>
</project>
----
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/bestpractices.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/bestpractices.adoc b/asciidoc/bestpractices.adoc
index 9158483..6d7c9fc 100644
--- a/asciidoc/bestpractices.adoc
+++ b/asciidoc/bestpractices.adoc
@@ -37,7 +37,7 @@ This is usually not a valid recommendation for open source projects, but for the
* control +
- The main problem with these kinds of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fix it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hides the one on the public repository, but this makes repository browsing and maintenance cumbersome.
+ The main problem with these kinds of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fix it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hides the one on the public repository, but this makes repository browsing and maintenance cumbersome.
Even more problematic is the possible updates of the repository. We know that versions published in such repositories should be stable and not be updated, but we also frequently see that a module descriptor is buggy, or an artifact corrupted. We even see sometimes a new version published with the same name as the preceding one because the previous one was simply badly packaged. This can occur even to the best; it occurred to us with Ivy 1.2 :-) But then we decided to publish the new version with a different name, 1.2a. But if the repository manager allows such updates, this means that what worked before can break. It can thus break your build reproducibility.
* reliability +
@@ -54,17 +54,17 @@ Note that using an enterprise repository doesn't mean you have to build it entir
== Always use patterns with at least organisation and module
-Ivy is very flexible and can accomodate a lot of existing repositories, using the concept of link:concept.html#pattern[patterns]. But if your repository doesn't exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like link:use/install.html[install] or link:use/repreport.html[repreport].
+Ivy is very flexible and can accommodate a lot of existing repositories, using the concept of link:concept.html#pattern[patterns]. But if your repository doesn't exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like link:use/install.html[install] or link:use/repreport.html[repreport].
== Public ivysettings.xml with public repositories
-If you create a public repository, provide a URL to the link:settings.html[ivysettings.xml] file. It's pretty easy to do, and if someone wants to leverage your repository, he will just have to load it with link:use/settings.html[settings] with the URL of your ivysettings.xml file, or link:configuration/include.html[include] it in its own configuration file, which makes it really easy to combine several public repositories.
+If you create a public repository, provide a URL to the link:settings.html[ivysettings.xml] file. It's pretty easy to do, and if someone wants to leverage your repository, he will just have to load it with link:use/settings.html[settings] with the URL of your ivysettings.xml file, or link:settings/include.html[include] it in its own configuration file, which makes it really easy to combine several public repositories.
== Dealing with integration versions
-Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.
+Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.
If you follow the continuous integration paradigm across modules, these integration versions can be produced by a continuous integration server, very frequently.
@@ -74,7 +74,7 @@ There are basically two ways to deal with them, both ways being supported by Ivy
* use a naming convention like a special suffix +
- the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but checks the date of the version on the repository and sees if it has changed. In Ivy this is supported using the link:ivyfile/dependency.html[changing attribute] on a dependency or by configuring the link:configuration/resolvers.html[changing pattern] to use for all your modules.
+ the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but checks the date of the version on the repository and sees if it has changed. In Ivy this is supported using the link:ivyfile/dependency.html[changing attribute] on a dependency or by configuring the link:settings/resolvers.html[changing pattern] to use for all your modules.
* automatically create a new version for each +
in this case you use either a build number or a timestamp to publish each new integration version with a new version name. Then you can use one of the numerous ways in Ivy to link:ivyfile/dependency.html[express a version constraint]. Usually selecting the very latest one (using 'latest.integration' as version constraint) is enough.
@@ -82,7 +82,7 @@ There are basically two ways to deal with them, both ways being supported by Ivy
So, which way is the best? As often, it depends on your context, and if one of the two was really bad it wouldn't be supported in Ivy :-)
-But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make *all* your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.
+But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make *all* your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.
Imagine you have a customer who comes on a Monday morning and asks for the latest version of your software, for testing or demonstration purposes. Obviously he needs it for the afternoon :-) Now if you have a continuous integration process and good tracking of your changes and your artifacts, it may occur to you that you are actually able to fulfill his request without needing the use of a DeLorean to give you some more time :-) But it may also occur to you that your latest version is stable enough to be used for the purpose of the customer, but was actually built a few days ago, because the very latest just broke a feature or introduced a new one you don't want to deliver. You can deliver this 'stable' integration build if you want, but rest assured that a few days, or weeks, or even months later, the customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we all know how they are :-)
@@ -95,7 +95,7 @@ On the other hand, the main drawback of this solution is that it can produce a l
== Inlining dependencies or not?
-With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This pratice is called inlining. But what is it good for, and when should it be avoided?
+With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This practice is called inlining. But what is it good for, and when should it be avoided?
Putting ivy dependencies in a separate file has the following advantages:
@@ -116,12 +116,12 @@ On the other hand, using inline dependencies is very useful when:
Without ivy you usually either copy the custom task jar in ant lib, which requires maintenance of your workstation installation, or use a manual copy or download and a taskdef with the appropriate classpath, which is better. But if you have several custom tasks, or if they have themselves dependencies, it can become cumbersome. Using Ivy with an inline dependency is an elegant way to solve this problem.
* you want to easily deploy an application +
- If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybee packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of *any* version of your application available in your repository!
+ If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybe packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of *any* version of your application available in your repository!
== Hire an expert
-Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.
+Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.
Therefore hiring a build and dependency expert to analyse and improve your build and release system is most of the time a very good choice.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/compatibility.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/compatibility.adoc b/asciidoc/compatibility.adoc
index 0ba6891..131fbfd 100644
--- a/asciidoc/compatibility.adoc
+++ b/asciidoc/compatibility.adoc
@@ -17,7 +17,7 @@
under the License.
////
-== JVM compability
+== JVM compatibility
Up to Ivy 2.3.x, a minimum of Java 1.4 is required.
@@ -43,4 +43,3 @@ The required versions of the Apache HttpClient, Jsch or any optional dependency
Ivy does not at this time support multithreaded use. It thus should not be used with the ant `<parallel>` task.
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/concept.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/concept.adoc b/asciidoc/concept.adoc
index ee92657..c9a717b 100644
--- a/asciidoc/concept.adoc
+++ b/asciidoc/concept.adoc
@@ -54,10 +54,10 @@ For details on how to declare your module configurations, how to declare in whic
During configuration, ivy allows you to define what are called ivy variables. Ivy variables can be seen as ant properties, and are used in a very similar way. In particular, you use a properties tag in the configuration file to load a properties file containing ivy variables and their values.
-But the main differences between ant properties and ivy variables are that ivy variables can be overridden, whereas ant
+But the main differences between ant properties and ivy variables are that ivy variables can be overridden, whereas ant
properties can't, and that they are defined in separate environments.
-Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant).
+Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant).
This means that if you define an ant property after the call to configure, it will not be available as an ivy variable.
On the other hand, ivy variables are NOT exported to ant, thus if you define ivy variables in ivy, do not try to use them as ant properties.
@@ -69,7 +69,7 @@ Finally, it's also important to be aware of the time of substitution of variable
Moreover, in an ant environment, a bunch of variables are going to be set by default via the ant property file loading mechanism (actually they are first loaded as ant properties and then imported as ivy variables, see link:ant.html[Ant Tasks]), and even in the ant properties themselves there is going to be eager substitution on loading, effectively making it impossible to override some variable purely via the ivysettings.properties file. Some variables will really only be able to be overridden via ant properties because of this.
-Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens.
+Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens.
See the Patterns chapter below for what pattern tokens are.
== [[patterns]]Patterns
@@ -81,9 +81,9 @@ First let's give an example. You can for instance configure the file system depe
a pattern to find artifacts. This pattern can be like this:
myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
-This pattern indicates that the repository we use is in a directory called myrepository.
+This pattern indicates that the repository we use is in a directory called myrepository.
-In this directory we have directories having for name the name of the organisation of the module we look for.
+In this directory we have directories having for name the name of the organisation of the module we look for.
Then we have a directory per module, each having for name the name of the module.
Then in module directories we find a directory per artifact type (jars, wars, ivys, ...), in which we find artifacts named by the artifact id, followed by a hyphen, then the revision, a dot, and the artifact extension.
Not too difficult to understand is it? That's it, you have understood the pattern concept!
@@ -103,7 +103,7 @@ But here are all the tokens currently available:
the organisation name
* [orgPath] *__(since 2.3)__* +
- the organisation name where '.' has been replaced by '/'. This can be used to configure maven2-like repositories.
+ the organisation name where '.' has been replaced by '/'. This can be used to configure maven2-like repositories.
* [module] +
the module name
@@ -140,10 +140,10 @@ So if you surround a token with '(' and ')', any other text which is between the
For instance, suppose the pattern: "abc(def[type]ghi)"
type = "jar" -> the substituted pattern: abcdefjarghi
-type = null or "" -> the substitued pattern: abc
+type = null or "" -> the substituted pattern: abc
A more real life example:
-The pattern
+The pattern
[source]
----
[artifact](-[revision]).[ext]
@@ -216,7 +216,7 @@ Note also that with any matcher, the character '*' has the special meaning of ma
== [[extra]]Extra attributes
*__since 1.4__*
-Several tags in ivy xml files are extensible with what is called extra attributes.
+Several tags in ivy xml files are extensible with what is called extra attributes.
The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns.
*__since 2.0__*
@@ -239,13 +239,13 @@ Here is an ivy file with the attribute 'color' set to blue:
----
-Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes
+Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes
will indeed be used as identifiers for the module like the org the name and the revision:
[source]
----
-<dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
+<dependency org="apache" name="foo" e:color="blue" rev="1.5+"/>
----
@@ -260,7 +260,7 @@ ${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
Note that in patterns you must use the unqualified attribute name (no namespace prefix).
-If you don't want to use xml namespaces, it's possible but you will need to disable ivy file validation, since your files won't fulffill anymore the official ivy xsd. See the link:settings/settings.html[settings documentation] to see how to disable validation.
+If you don't want to use xml namespaces, it's possible but you will need to disable ivy file validation, since your files won't fulfill anymore the official ivy xsd. See the link:settings/settings.html[settings documentation] to see how to disable validation.
== [[checksum]]Checksums
@@ -283,12 +283,12 @@ If you want to change this default, you can set the variable ivy.checksums. Henc
=== Supported algorithms
*__since 1.4__*
-
-
+
+
* md5 +
-
+
* sha1 +
-
+
*__since 2.5__*
Starting 2.5 version, in addition to md5 and sha1, Ivy supports SHA-256, SHA-512 and SHA-384 algorithms, if the Java runtime in which Ivy is running, supports those. For example, Java 6 runtime supports SHA-256 and SHA-512 as standard algorithms. If Ivy 2.5 and later versions are run under Java 6 or higher runtimes, these algorithms are supported by Ivy too.
@@ -298,7 +298,7 @@ Starting 2.5 version, in addition to md5 and sha1, Ivy supports SHA-256, SHA-512
*__since 1.4__*
When Ivy performs the dependency resolution and some other tasks, it fires events before and after the most important steps. You can listen to these events using Ivy API, or you can even register a trigger to perform a particular action when a particular event occur.
-This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accuratly, and so on.
+This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accurately, and so on.
For more details about events and triggers, see the link:settings/triggers.html[triggers] documentation page in the configuration section of this documentation.
@@ -328,7 +328,7 @@ See the link:settings/settings.html[configuration page] to see how to configure
== Cache and Change Management
-Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.
+Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.
=== [[cache]]Cache types
@@ -338,7 +338,7 @@ An Ivy cache is composed of two different parts:
* the repository cache +
The repository cache is where Ivy stores data downloaded from module repositories, along with some meta information concerning these artifacts, like their original location.
-This part of the cache can be shared if you use a well suited link:settings/lock-strategies.html[lock strategy].
+This part of the cache can be shared if you use a well suited link:settings/lock-strategies.html[lock strategy].
* the resolution cache +
This part of the cache is used to store resolution data, which is used by Ivy to reuse the results of a resolve process.
@@ -350,7 +350,7 @@ While there is always only one resolution cache, you can link:settings/caches.ht
=== [[change]]Change management
-To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several link:bestpractices.html[good reasons] to follow this principle.
+To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several link:bestpractices.html[good reasons] to follow this principle.
However, depending on your current build system and your dependency management strategy, you may prefer to update your modules sometimes. There are two kinds of changes to consider:
@@ -374,7 +374,7 @@ So if you want to use changing revisions, use the link:use/publish.html[publish]
As a dependency manager, Ivy has a lot of file related operations, which most of the time use paths or path patterns to locate the file on the filesystem.
-These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like
+These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like
[source]
----
${ivy.basedir}/ivy.xml
@@ -396,15 +396,15 @@ If you really want to use relative paths, the base directory used to actually lo
== [[packaging]]Packaging
-Most of the artifacts found in a repository are jars. They can be downoaded and used as is. But some other kind of artifacts required some __unpacking__ after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with *packaging*.
+Most of the artifacts found in a repository are jars. They can be downloaded and used as is. But some other kind of artifacts required some __unpacking__ after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with *packaging*.
A __packaged__ artifact needs to be declared as such in the module descriptor via the attribute link:ivyfile/artifact.html[packaging]. The value of that attribute defined which kind of unpacking algorithm must be used. Here are the list of currently supported algorithms:
-
+
* `zip`, `jar` or `war`: the artifact will be uncompressed as a folder +
-
+
* `pack200`: the artifact will be unpacked to a file via the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm +
-
+
* `bundle`: the OSGi artifact will be uncompressed as a folder, and every embedded jar file entry which is packed via the the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm will be unpacked +
@@ -413,10 +413,10 @@ So, if in an `ivy.xml`, there would be declared a such artifact:
[source]
----
- <artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200" />
+ <artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200"/>
----
-A file `mymodule-1.2.3.jar.pack.gz` would be download into the cache, and also uncompressed in the cache to `mymodule-1.2.3.jar`. Then any post resolve task which supports it, like the link:use/cachepath.html[cachepath], will use the uncompressed file instead of the orginal compressed file.
+A file `mymodule-1.2.3.jar.pack.gz` would be download into the cache, and also uncompressed in the cache to `mymodule-1.2.3.jar`. Then any post resolve task which supports it, like the link:use/cachepath.html[cachepath], will use the uncompressed file instead of the original compressed file.
It is possible to chain packing algorithm. The attribute link:ivyfile/artifact.html[packaging] of a artifact expects a comma separated list of packing types, in packing order. For instance, an artifact '`mymodule-1.2.3.jar.pack.gz`' can have the packaging '`jar,pack200`', so it would be uncompressed as a folder '`mymodule-1.2.3`'.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/configuration/caches/cache.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/caches/cache.adoc b/asciidoc/configuration/caches/cache.adoc
index faadfe4..a133893 100644
--- a/asciidoc/configuration/caches/cache.adoc
+++ b/asciidoc/configuration/caches/cache.adoc
@@ -17,4 +17,4 @@
under the License.
////
This page has moved. If your browser doesn't automatically redirect to its new location, click
-link:../../settings/caches/cache.html[here].
+link:../../settings/caches/cache.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/configuration/caches/ttl.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/caches/ttl.adoc b/asciidoc/configuration/caches/ttl.adoc
index ca1de28..d50d1ae 100644
--- a/asciidoc/configuration/caches/ttl.adoc
+++ b/asciidoc/configuration/caches/ttl.adoc
@@ -18,4 +18,4 @@
////
This page has moved. If your browser doesn't automatically redirect to its new location, click
-link:../../settings/caches/ttl.html[here].
+link:../../settings/caches/ttl.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/configuration/macrodef/attribute.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/macrodef/attribute.adoc b/asciidoc/configuration/macrodef/attribute.adoc
index 27510e4..4d3c143 100644
--- a/asciidoc/configuration/macrodef/attribute.adoc
+++ b/asciidoc/configuration/macrodef/attribute.adoc
@@ -18,4 +18,4 @@
////
This page has moved. If your browser doesn't automatically redirect to its new location, click
-link:../../settings/macrodef/attribute.html[here].
+link:../../settings/macrodef/attribute.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/configuration/namespace/dest.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/configuration/namespace/dest.adoc b/asciidoc/configuration/namespace/dest.adoc
index 316431b..b938e6a 100644
--- a/asciidoc/configuration/namespace/dest.adoc
+++ b/asciidoc/configuration/namespace/dest.adoc
@@ -18,4 +18,4 @@
////
This page has moved. If your browser doesn't automatically redirect to its new location, click
-link:../../settings/namespace/dest.html[here].
+link:../../settings/namespace/dest.html[here].
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/dev.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev.adoc b/asciidoc/dev.adoc
index 901362b..aadf5b5 100644
--- a/asciidoc/dev.adoc
+++ b/asciidoc/dev.adoc
@@ -20,11 +20,11 @@
== Building from source
-To build Ivy from source it's really easy.
+To build Ivy from source it's really easy.
=== Requirements
-All you need is
+All you need is
* an link:http://subversion.tigris.org/[svn] client +
@@ -135,7 +135,7 @@ Download the file and unzip its content in your eclipse installation directory.
=== recommended plugins
-The Ivy project comes with settings for the link:http://eclipse-cs.sourceforge.net/[checkstyle plugin] we recommend to use to avoid introducing new disgression to the checkstyle rules we use.
+The Ivy project comes with settings for the link:http://eclipse-cs.sourceforge.net/[checkstyle plugin] we recommend to use to avoid introducing new digression to the checkstyle rules we use.
If you use this plugin, you will many errors in Ivy. As we said, following strict checkstyle rules is a work in progress and we used to have pretty different code conventions (like using _ as prefix for private attributes), so we still have things to fix. We usually use the filter in the problems view to filter out checkstyle errors from this view, which helps to know what the real compilation problem are.
Besides this plugin we also recommend to use a subversion plugin, link:http://www.eclipse.org/subversive/[subversive] or link:http://subclipse.tigris.org[subclipse] being the two options currently available in the open source landscape.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/dev/makerelease.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/dev/makerelease.adoc b/asciidoc/dev/makerelease.adoc
index 605740d..4dc4849 100644
--- a/asciidoc/dev/makerelease.adoc
+++ b/asciidoc/dev/makerelease.adoc
@@ -92,7 +92,7 @@ You can also do a smoke test with the generated ivy.jar, to see if it is able to
==== 6. Sign the artifacts
-It's now time to sign the release artifacts and upload them to a location accessible by other Apache commiters.
+It's now time to sign the release artifacts and upload them to a location accessible by other Apache committers.
Here is a simple way to sign the files using gnupg:
@@ -110,7 +110,7 @@ Here is a ruby script you can use to sign the files:
require 'find'
-Find.find('build/distrib') do |f|
+Find.find('build/distrib') do |f|
`gpg --armor --output #{f}.asc --detach-sig #{f}` if File.file?(f) && ['.zip', '.gz', '.jar', '.pom'].include?(File.extname(f))
end
@@ -154,7 +154,7 @@ ant -f build-release.xml upload-nexus
----
-Once uploaded, log in https://repository.apache.org/ with your prefered web browser (use your Apache ID).
+Once uploaded, log in https://repository.apache.org/ with your preferred web browser (use your Apache ID).
You should find there an __open__ repository with the name of the form `orgapacheant-XXXX`. It should contain the Maven artifacts: the pom, the jar, the sources, the javadocs and the md5 and asc files.
@@ -179,7 +179,7 @@ And push the changes to the ASF repo
[source]
----
-git push --tags
+git push --tags
----
@@ -229,13 +229,13 @@ $ svn mv https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION https://dist.ap
----
-In order to keep the main dist area of a reasonable size, old releases should be removed. They will disapear from the main dist but will still be available via the link:http://archive.apache.org/dist/ant/ivy/[archive]. To do so, just use the `svn rm` command against the artifacts or folders to remove.
+In order to keep the main dist area of a reasonable size, old releases should be removed. They will disappear from the main dist but will still be available via the link:http://archive.apache.org/dist/ant/ivy/[archive]. To do so, just use the `svn rm` command against the artifacts or folders to remove.
==== 13. Promote the Maven staging repository
-Go log in https://repository.apache.org/ with your prefered web browser (use your Apache ID).
+Go log in https://repository.apache.org/ with your preferred web browser (use your Apache ID).
Select the appropriate `orgapacheant-XXXX` repository and select the __Release__ action.
@@ -293,9 +293,9 @@ ant /all generate-site
----
-You should verify that the site generated in the production directory is OK. You can open the files with your prefered web browser like it was deployed.
+You should verify that the site generated in the production directory is OK. You can open the files with your preferred web browser like it was deployed.
-And once your happy with it, commit the changes in the source directory, and in the production directoy to get it actually deployed via svnpubsub.
+And once your happy with it, commit the changes in the source directory, and in the production directory to get it actually deployed via svnpubsub.
Tip: lot's of files might need to be 'added' to svn. An handy command to `add` any file which is not yet under version control is the following one:
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/index.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/index.adoc b/asciidoc/index.adoc
index e25349b..da35c0b 100644
--- a/asciidoc/index.adoc
+++ b/asciidoc/index.adoc
@@ -34,7 +34,7 @@ Ivy is open source and released under a very permissive link:https://ant.apache.
Ivy has a lot of powerful link:https://ant.apache.org/ivy/features.html[features], the most popular and useful being its flexibility, integration with ant, and its strong transitive dependencies management engine.
-The transitive dependencies management is a feature which lets you get dependencies of your dependencies, transitively. In order to address this general problem, ivy needs to find metadata about your modules, usually in an link:ivyfile.html[ivy file]. To find the metadata and your dependencies' artifacts (usually jars), Ivy can be configured to use a lot of different link:configuration/resolvers.html[repositories].
+The transitive dependencies management is a feature which lets you get dependencies of your dependencies, transitively. In order to address this general problem, ivy needs to find metadata about your modules, usually in an link:ivyfile.html[ivy file]. To find the metadata and your dependencies' artifacts (usually jars), Ivy can be configured to use a lot of different link:settings/resolvers.html[repositories].
== About this doc
@@ -62,7 +62,7 @@ For earlier versions, we suggest downloading the documentation to browse the doc
== Other places to go
-Check out Ivy link:https://ant.apache.org/ivy/features.html[features]. +
+Check out Ivy link:https://ant.apache.org/ivy/features.html[features]. +
Read our link:https://ant.apache.org/ivy/faq.html[FAQ]. +
Ask for help on our link:https://ant.apache.org/ivy/mailing-lists.html[mailing lists]. +
Report a bug or feature request in our link:https://ant.apache.org/ivy/issues.html[issue tracking system]. +
@@ -73,15 +73,14 @@ Check link:https://ant.apache.org/ivy/links.html[external tools and resources].
This documentation is composed of three main parts:
-
-* link:tutorial.html[Tutorials] +
+
+* link:tutorial.html[Tutorials] +
The tutorials is the best way to begin to play with Ivy. You will easily and quickly learn the basics of Ivy.
-
-* link:reference.html[Reference] +
-The reference documentation gives you all the details of Ivy.
-The introduction part is particularly useful: it defines some vocabulary, explains main concepts such as dependency resolvers and patterns, and gives an overview of how ivy works internally.
+
+* link:reference.html[Reference] +
+The reference documentation gives you all the details of Ivy.
+The introduction part is particularly useful: it defines some vocabulary, explains main concepts such as dependency resolvers and patterns, and gives an overview of how ivy works internally.
It's also in the reference doc that you will find all you always dreamed to know about ivy settings, ivy files, and ivy use (especially with ant).
-
-* link:dev.html[Developer doc] +
-The developers's doc is useful for users who would like to extend Ivy or build it from source. It's also the documentation used by the Ivy team, so you will also find information about how we make releases.
+* link:dev.html[Developer doc] +
+The developers's doc is useful for users who would like to extend Ivy or build it from source. It's also the documentation used by the Ivy team, so you will also find information about how we make releases.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/install.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/install.adoc b/asciidoc/install.adoc
index f55162e..54e0887 100644
--- a/asciidoc/install.adoc
+++ b/asciidoc/install.adoc
@@ -26,7 +26,7 @@ Download the version you want here, unpack the downloaded zip file wherever you
If you use ant 1.6.0 or superior, you can then simply go to the src/example/hello-ivy dir and run ant: if the build is successful, you have successfully installed Ivy!
If you use ant 1.5.1 or superior, you have to modify the build files in the examples:
-- remove the namespace section at their head: xmlns:ivy="antlib:org.apache.ivy.ant"
+- remove the namespace section at their head: xmlns:ivy="antlib:org.apache.ivy.ant"
- add taskdefs for ivy tasks:
[source]
@@ -35,7 +35,7 @@ If you use ant 1.5.1 or superior, you have to modify the build files in the exam
<taskdef name="ivy-configure" classname="org.apache.ivy.ant.IvyConfigure"/>
<taskdef name="ivy-resolve" classname="org.apache.ivy.ant.IvyResolve"/>
<taskdef name="ivy-retrieve" classname="org.apache.ivy.ant.IvyRetrieve"/>
- <taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
+ <taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
----
@@ -45,7 +45,7 @@ You can now run the build, if it is successful, you have successfully installed
If the build is not successful, check the FAQ to see what might be the problem with the ivyrep resolver.
-=== Ivy dependendencies
+=== Ivy dependencies
One of the two binary versions of Ivy doesn't include the optional dependencies. To download them using Ivy, all you need is to run the Ant build file provided in the distribution. This will use Ivy itself to download the dependencies. Then you should see the Ivy optional dependencies in the lib directory, organized per configuration (see the ivy.xml for details about the configurations and their use).
@@ -58,19 +58,19 @@ If you want to use Ivy only in your ant build scripts, and have an internet conn
[source]
----
- <property name="ivy.install.version" value="2.1.0-rc2" />
+ <property name="ivy.install.version" value="2.1.0-rc2"/>
<condition property="ivy.home" value="${env.IVY_HOME}">
- <isset property="env.IVY_HOME" />
+ <isset property="env.IVY_HOME"/>
</condition>
- <property name="ivy.home" value="${user.home}/.ant" />
- <property name="ivy.jar.dir" value="${ivy.home}/lib" />
- <property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar" />
+ <property name="ivy.home" value="${user.home}/.ant"/>
+ <property name="ivy.jar.dir" value="${ivy.home}/lib"/>
+ <property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar"/>
<target name="download-ivy" unless="offline">
<mkdir dir="${ivy.jar.dir}"/>
<!-- download Ivy from web site so that it can be used even without any special installation -->
- <get src="https://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
+ <get src="https://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
dest="${ivy.jar.file}" usetimestamp="true"/>
</target>
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile.adoc b/asciidoc/ivyfile.adoc
index dcd38e4..9bc46ab 100644
--- a/asciidoc/ivyfile.adoc
+++ b/asciidoc/ivyfile.adoc
@@ -25,8 +25,7 @@ Here is the simplest ivy file you can write:
----
<ivy-module version="2.0">
<info organisation="myorg"
- module="mymodule"
- />
+ module="mymodule"/>
</ivy-module>
----
@@ -39,13 +38,12 @@ For those familiar with xml schema, the schema used to validate ivy files can be
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
-<ivy-module version="2.0"
+<ivy-module version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://ant.apache.org/ivy/schemas/ivy.xsd">
<info organisation="myorg"
- module="mymodule"
- />
+ module="mymodule"/>
</ivy-module>
----
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/artifact-conf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/artifact-conf.adoc b/asciidoc/ivyfile/artifact-conf.adoc
index 4ba0475..46cbd7a 100644
--- a/asciidoc/ivyfile/artifact-conf.adoc
+++ b/asciidoc/ivyfile/artifact-conf.adoc
@@ -26,7 +26,7 @@ Indicates a public configuration in which enclosing artifact is published.
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|name|the name of the module public configuration in which this artifact is published.
+|name|the name of the module public configuration in which this artifact is published.
`$$*$$` wildcard can be used to designate all public configurations of this module|Yes
|=======
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/artifact-exclude.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/artifact-exclude.adoc b/asciidoc/ivyfile/artifact-exclude.adoc
index d27964a..7269c6d 100644
--- a/asciidoc/ivyfile/artifact-exclude.adoc
+++ b/asciidoc/ivyfile/artifact-exclude.adoc
@@ -19,7 +19,9 @@
*Tag:* exclude *Parent:* link:../ivyfile/dependency.html[dependency]
-This feature gives you more control on a dependency for which you do not control its ivy file. It enables to restrict the artifacts required, by excluding artifacts being published by the dependency or any of its transitive dependencies, even if configuration does not a good separation of published artifacts
+This feature gives you more control on a dependency for which you do not control its ivy file.
+It enables to restrict the artifacts required, by excluding artifacts being published by the dependency or any of its transitive dependencies,
+even if configuration does not a good separation of published artifacts
The same principle concerning configuration as for include applies to this exclude feature (see the link:../ivyfile/dependency-include.html[include] feature).
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/artifact.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/artifact.adoc b/asciidoc/ivyfile/artifact.adoc
index d173453..e4ebb2e 100644
--- a/asciidoc/ivyfile/artifact.adoc
+++ b/asciidoc/ivyfile/artifact.adoc
@@ -19,7 +19,7 @@
*Tag:* artifact *Parent:* link:../ivyfile/publications.html[publications]
-Declares an artifact published by this module. This is especially useful for other modules dependending on this one. They thus get all published artifacts belonging to the configurations asked. Indeed, each published artifact declares in which public configuration it is published. Thus a module depending on this module only get artifacts marked with the asked configurations, taking into account configurations extension (see link:../ivyfile/conf.html[configuration declaration]).
+Declares an artifact published by this module. This is especially useful for other modules depending on this one. They thus get all published artifacts belonging to the configurations asked. Indeed, each published artifact declares in which public configuration it is published. Thus a module depending on this module only get artifacts marked with the asked configurations, taking into account configurations extension (see link:../ivyfile/conf.html[configuration declaration]).
The configurations in which an artifact is published can be configured in two ways:
@@ -31,7 +31,7 @@ The two are equivalent, it is only a matter of preference. However, do not mix b
*__since 1.4__* The artifact element has default values for all its attributes, so if you want to declare a default artifact you can just declare it like that:
[source,xml]
----
-<artifact />
+<artifact/>
----
If this is the only artifact declared, then it's equivalent to having no publication section at all.
@@ -69,7 +69,7 @@ If this is the only artifact declared, then it's equivalent to having no publica
[source,xml]
----
-<artifact />
+<artifact/>
----
Declares an artifact with the name of the module as name, type and ext jar, and published in all configurations.
@@ -78,7 +78,7 @@ Declares an artifact with the name of the module as name, type and ext jar, and
[source,xml]
----
-<artifact name="foo-src" type="source" ext="zip" conf="src" />
+<artifact name="foo-src" type="source" ext="zip" conf="src"/>
----
Declares an artifact `foo-src`, of type `source` with extension `zip`, and published in the `src` configuration.
@@ -87,7 +87,7 @@ Declares an artifact `foo-src`, of type `source` with extension `zip`, and publi
[source,xml]
----
-<artifact name="foo" url="http://www.acme.com/repository/barbaz/foo-1.2-bar.jar" />
+<artifact name="foo" url="http://www.acme.com/repository/barbaz/foo-1.2-bar.jar"/>
----
Declares an artifact `foo`, of type and extension `jar'` located at the url `$$http://www.acme.com/repository/barbaz/foo-1.2-bar.jar$$`. This url will only be used if the artifact cannot be found at its standard location.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/conf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/conf.adoc b/asciidoc/ivyfile/conf.adoc
index 79811e0..abe1067 100644
--- a/asciidoc/ivyfile/conf.adoc
+++ b/asciidoc/ivyfile/conf.adoc
@@ -19,7 +19,7 @@
*Tag:* conf *Parent:* link:../ivyfile/configurations.html[configurations]
-Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in Ivy module configurations.
+Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those different ways to use or build a module are called in Ivy module configurations.
The `conf` element in the configurations section declares one configuration. This declaration gives the name of the configuration declared, its visibility and the other configurations of the module it extends.
@@ -37,7 +37,7 @@ This notion is very helpful to define configurations which are similar with some
|`*(private)`|all other private configurations
|=======
-*__since 1.4__* A whole configuration can be declared as non transitive, so that all dependencies resolved in this configuration will be resolved with transitivity disabled. Note that the transitivity is disabled for all the configuration dependencies (including those obtained because this conf extends other ones), and only for this configuration (which means that a conf extending this one with transitivityy enabled will get transitive dependencies even for dependencies being part of the non transitive configuration).
+*__since 1.4__* A whole configuration can be declared as non transitive, so that all dependencies resolved in this configuration will be resolved with transitivity disabled. Note that the transitivity is disabled for all the configuration dependencies (including those obtained because this conf extends other ones), and only for this configuration (which means that a conf extending this one with transitivity enabled will get transitive dependencies even for dependencies being part of the non transitive configuration).
This is very useful to build a compile configuration, for instance, forcing the dependency declaration on each direct dependency, with no risk to forget some because of transitivity.
*__since 1.4__* This tag supports link:../concept.html#extra[extra attributes].
@@ -52,8 +52,7 @@ This is very useful to build a compile configuration, for instance, forcing the
|visibility|the visibility of the declared configuration.
`public` means that this configuration can be used by other modules, while `private` means that this configuration is used only in the module itself, and is not exposed to other modules|No, defaults to `public`
-|extends|a comma separated list of configurations of this module that the
- current configuration extends|No, defaults to none
+|extends|a comma separated list of configurations of this module that the current configuration extends|No, defaults to none
|transitive|a boolean to indicate if this conf is transitive or not *__since 1.4__*|No, defaults to `true`
|deprecated|indicates that this conf has been deprecated by giving the date of the deprecation.
@@ -64,11 +63,11 @@ It should be given in this format: `yyyyMMddHHmmss`|No, by default the conf is n
[source,xml]
----
-<conf name="core" visibility="private" />
-<conf name="compile" extends="core" transitive="false" visibility="private" />
-<conf name="runtime" extends="compile" description="everything needed to run this module" />
+<conf name="core" visibility="private"/>
+<conf name="compile" extends="core" transitive="false" visibility="private"/>
+<conf name="runtime" extends="compile" description="everything needed to run this module"/>
----
Declares three configurations, `core`, `compile` and `runtime`, with only the `runtime` one accessible from other modules, and with the `compile` one being non transitive.
-Therefore the `core` configuration will only be composed of dependencies declared in the `core` configuration itself, the `compile` configuration will be composed of all dependencies required in either `core` or `compile` configuration, but without transivity (neither for core nor compile dependencies), and `runtime` will be composed of all dependencies, all transitively, including the dependencies declared only in `compile`.
+Therefore the `core` configuration will only be composed of dependencies declared in the `core` configuration itself, the `compile` configuration will be composed of all dependencies required in either `core` or `compile` configuration, but without transitivity (neither for core nor compile dependencies), and `runtime` will be composed of all dependencies, all transitively, including the dependencies declared only in `compile`.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/configurations.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/configurations.adoc b/asciidoc/ivyfile/configurations.adoc
index e944830..6409062 100644
--- a/asciidoc/ivyfile/configurations.adoc
+++ b/asciidoc/ivyfile/configurations.adoc
@@ -62,18 +62,18 @@ For instance, say you have:
[source,xml]
----
<configurations defaultconfmapping="conf1->other1;conf2->other2">
- <conf name="conf1" />
- <conf name="conf2" extends="conf1" />
+ <conf name="conf1"/>
+ <conf name="conf2" extends="conf1"/>
</configurations>
<dependencies>
- <dependency name="other-module" conf="conf1" />
+ <dependency name="other-module" conf="conf1"/>
</dependencies>
----
When Ivy parses this file, it will construct the following dependency (in-memory only):
[source,xml]
----
-<dependency name="other-module" conf="conf1->other1" />
+<dependency name="other-module" conf="conf1->other1"/>
----
So, if you now resolve the `conf2` configuration, you will only get the other1 dependencies of your other-module.
@@ -82,7 +82,7 @@ But when you set `confmappingoverride` to `true`, Ivy will construct the followi
[source,xml]
----
-<dependency name="other-module" conf="conf1->other1;conf2->other2" />
+<dependency name="other-module" conf="conf1->other1;conf2->other2"/>
----
As you can see, the `defaultmappings` of the extending configurations are also added (although you didn't explicitly defined them)
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/conflict.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/conflict.adoc b/asciidoc/ivyfile/conflict.adoc
index 2cddacc..f2dd7a1 100644
--- a/asciidoc/ivyfile/conflict.adoc
+++ b/asciidoc/ivyfile/conflict.adoc
@@ -32,7 +32,7 @@ There are two things optimized during conflict resolution: download of artifacts
That's why the order of dependencies is important for download optimization. Indeed ivy traverses the dependency graph in the order in which dependencies are declared in the ivy files, and each time it encounters a dependency on a module, it first check if there is a conflict on this module, and if this is the case, it asks the conflict manager to resolve the conflict. Then if the module is evicted, it does not download its ivy file, and the whole branch is not traversed, which can saves a lot of time.
If no specific conflict manager is defined, a default conflict manager is used for all modules.
-
+
The current default conflict manager is the `latest-revision` conflict manager.
== Attributes
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/conflicts.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/conflicts.adoc b/asciidoc/ivyfile/conflicts.adoc
index c517bfb..d0622fd 100644
--- a/asciidoc/ivyfile/conflicts.adoc
+++ b/asciidoc/ivyfile/conflicts.adoc
@@ -22,7 +22,7 @@
*__(since 2.0)__* the conflicts section is deprecated. Use the link:../ivyfile/conflict.html[conflict] instead.
Container for conflict manager elements, used to indicate how conflicts should be resolved
-for this module.
+for this module.
The list of built-in conflict managers available is listed on the link:../settings/conflict-managers.html[conflict manager configuration page].
@@ -37,13 +37,13 @@ ivy needs to know the dependency graph, and to know the dependency graph, it has
ivy files. But ivy is highly optimized on this too, and it tries to evict modules as soon as possible.
That's why the order of dependencies is important for download optimization. Indeed ivy
-traverses the dependency graph in the order in which dependencies are declared in the ivy files,
-and each time it encounters a dependency on a module, it first check if there is a conflict on this module,
+traverses the dependency graph in the order in which dependencies are declared in the ivy files,
+and each time it encounters a dependency on a module, it first check if there is a conflict on this module,
and if this is the case, it asks the conflict manager to resolve the conflict. Then if the module is evicted,
it does not download its ivy file, and the whole branch is not traversed, which can saves
a lot of time.
-If this container is not present, a default conflict manager is used for all modules.
+If this container is not present, a default conflict manager is used for all modules.
The current default conflict manager is the `latest-revision` conflict manager.
== Child elements
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/dependencies.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/dependencies.adoc b/asciidoc/ivyfile/dependencies.adoc
index fe05aa8..7085ac9 100644
--- a/asciidoc/ivyfile/dependencies.adoc
+++ b/asciidoc/ivyfile/dependencies.adoc
@@ -19,7 +19,7 @@
*Tag:* dependencies *Parent:* link:../ivyfile.html[ivy-module]
-Container for dependency elements, used to describe the dependencies of this module.
+Container for dependency elements, used to describe the dependencies of this module.
If this container is not present, it is assumed that the module has no dependency at all.
This container provides for two similar behaviors. An overview is given here. (See link:../ivyfile/configurations.html[configurations doc page] for more details about these behaviors).
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/dependency-artifact.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/dependency-artifact.adoc b/asciidoc/ivyfile/dependency-artifact.adoc
index b7fef30..5006963 100644
--- a/asciidoc/ivyfile/dependency-artifact.adoc
+++ b/asciidoc/ivyfile/dependency-artifact.adoc
@@ -19,8 +19,8 @@
*Tag:* artifact *Parent:* link:../ivyfile/dependency.html[dependency]
-This feature gives you more control on a dependency for which you do not control its ivy file.
-It enables to specify the artifacts required, if the dependency has no ivy file.
+This feature gives you more control on a dependency for which you do not control its ivy file.
+It enables to specify the artifacts required, if the dependency has no ivy file.
Indeed, when a module has no ivy file, it is assumed that it publishes exactly one artifact having the same name as the module itself. But when this module publishes more artifacts, or simply does not respect the name rule, and if you cannot deliver an ivy file for it (because you do not control the repository, for instance - think about maven ibiblio repository, to give no name), then this feature let you specify the artifacts names you want to get.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/dependency-conf.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/dependency-conf.adoc b/asciidoc/ivyfile/dependency-conf.adoc
index 7d0fe38..b970308 100644
--- a/asciidoc/ivyfile/dependency-conf.adoc
+++ b/asciidoc/ivyfile/dependency-conf.adoc
@@ -26,7 +26,7 @@ Describes a configuration mapping for a dependency. See also the inline configur
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|name|the name of the master configuration to map.
+|name|the name of the master configuration to map.
`$$*$$` wildcard can be used to designate all configurations of this module|Yes
|mapped|a comma separated list of dependency configurations to which this master configuration should be mapped|No, default to the same configuration as master one, unless nested mapped elements are specified
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/dependency-include.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/dependency-include.adoc b/asciidoc/ivyfile/dependency-include.adoc
index 18645c6..70de200 100644
--- a/asciidoc/ivyfile/dependency-include.adoc
+++ b/asciidoc/ivyfile/dependency-include.adoc
@@ -19,7 +19,7 @@
*Tag:* include *Parent:* link:../ivyfile/dependency.html[dependency]
-This feature gives you more control on a dependency for which you do not control its ivy file.
+This feature gives you more control on a dependency for which you do not control its ivy file.
It enables to restrict the artifacts required by including only the artifacts given here, even if configuration does not a good separation of published artifacts.
Each artifact restriction can be given in the context of particular master configurations. By default, if no configuration is specified, artifacts restriction apply to all master configurations. But you can specify that a restriction applies only to one or several master configurations, using either inline or nested conf specification. In this case, do not forget that if you do not specify any restriction for a particular configuration, then no restriction will apply for this configuration and it will be resolved not taking into account any restriction.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/dependency.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/dependency.adoc b/asciidoc/ivyfile/dependency.adoc
index d6f3306..b64548e 100644
--- a/asciidoc/ivyfile/dependency.adoc
+++ b/asciidoc/ivyfile/dependency.adoc
@@ -56,7 +56,7 @@ The way to determine which revision is the "latest" between two is configurable
*__since 2.0__* The `dependency` tag supports two revision attributes: `rev`, corresponding to the default required dependency revision, and `revConstraint`, corresponding to a dynamic revision constraint applied on this dependency.
-Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a stic version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This both ensure better metadata in the repository while still allowing easier build reproducibility.
+Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a static version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This both ensure better metadata in the repository while still allowing easier build reproducibility.
== Configurations mapping
@@ -95,7 +95,7 @@ Example: Let's foo be a module with two configurations, A and B, B extending A.
If you don't understand really how this works, do not use it :-)
-*__since 1.4__* `%` can be used as left side operand to mean "all the other configurations". This can be usefull when you only have a specific mapping for some configurations and a default mapping for all the others. For instance, `$$test->runtime;%->default$$` means that the `test` configuration is mapped to the `runtime` configuration, but all the other configurations are mapped to the `default` configuration.
+*__since 1.4__* `%` can be used as left side operand to mean "all the other configurations". This can be useful when you only have a specific mapping for some configurations and a default mapping for all the others. For instance, `$$test->runtime;%->default$$` means that the `test` configuration is mapped to the `runtime` configuration, but all the other configurations are mapped to the `default` configuration.
*__since 1.3__* a fallback mechanism can be used when you are not sure that the dependency will have the required conf. You can indicate to ivy that you want one configuration, but if it isn't present, use another one.
The syntax for specifying this adds the fallback conf between parenthesis right after the required conf.
@@ -104,7 +104,7 @@ For instance, `$$test->runtime(default)$$` means that in the test configuration
*__since 2.1__* It is also possible to define dependencies on configurations intersection. A configuration intersection is defined using a `+` sign to separate the configuration (eg `A+B` means the intersection of configuration A and B). In that case only artifacts and dependencies defined in both configurations in the dependency will be part of the master configuration defining the dependency on the configuration intersection.
-Configuration intersections can also be used when specifying the confs to link:../use/resolve.html[resolve].
+Configuration intersections can also be used when specifying the confs to link:../use/resolve.html[resolve].
Moreover, the mapping `$$*->@$$` is handled as a specific case with configuration intersections: it maps also the intersections. So if one resolve conf `A+B` in a module which defines a dependency with mapping `$$*->@$$`, the mapping `$$*->@$$` is interpreted as `$$A+B->A+B$$` so the intersection of A and B will be resolved in the dependency.
@@ -114,10 +114,10 @@ For instance, if you have:
[source,xml]
----
<configurations>
- <conf name="red" e:axis="color" />
- <conf name="blue" e:axis="color" />
-
- <conf name="windows" e:axis="platform" />
+ <conf name="red" e:axis="color"/>
+ <conf name="blue" e:axis="color"/>
+
+ <conf name="windows" e:axis="platform"/>
<conf name="linux" e:axis="platform"/>
</configurations>
----
@@ -148,7 +148,7 @@ See link:../ivyfile/dependency-artifact.html[dependency artifact] for details.
Finally, the dependency element also supports an a force attribute (since 0.8), which gives an indication
to conflicts manager to force the revision of a dependency to the one given here.
-See link:../ivyfile/conflicts.html[conflicts manager] for details.
+See link:../ivyfile/conflicts.html[conflicts manager] for details.
*__since 1.4__* this tag supports link:../concept.html#extra[extra attributes]
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/exclude.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/exclude.adoc b/asciidoc/ivyfile/exclude.adoc
index d51079c..0f68454 100644
--- a/asciidoc/ivyfile/exclude.adoc
+++ b/asciidoc/ivyfile/exclude.adoc
@@ -19,7 +19,8 @@
*Tag:* exclude *Parent:* link:../ivyfile/dependencies.html[dependencies]
-*__since 2.0__* This feature gives you more control on a dependency for which you do not control its ivy file. It allows to exclude artifacts, modules or organizations from the list of dependencies for the whole module.
+*__since 2.0__* This feature gives you more control on a dependency for which you do not control its ivy file.
+It allows to exclude artifacts, modules or organizations from the list of dependencies for the whole module.
It is very similar to the link:../ivyfile/artifact-exclude.html[dependency exclude] element, except that it applies to a whole module, which can be very useful when a lot of dependencies transitively bring a module you don't want.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/include.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/include.adoc b/asciidoc/ivyfile/include.adoc
index 5582f8c..ee31883 100644
--- a/asciidoc/ivyfile/include.adoc
+++ b/asciidoc/ivyfile/include.adoc
@@ -41,8 +41,7 @@ When delivering an ivy file with such an inclusion, the included configuration f
----
<ivy-module version="1.0">
<info organisation="myorg"
- module="mymodule"
- />
+ module="mymodule"/>
<configurations>
<include file="path/to/included-configurations.xml"/>
<conf name="conf3"/>
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/info.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/info.adoc b/asciidoc/ivyfile/info.adoc
index 7213d91..1341746 100644
--- a/asciidoc/ivyfile/info.adoc
+++ b/asciidoc/ivyfile/info.adoc
@@ -49,4 +49,3 @@ Gives identification and basic information about the module this ivy file descri
|=======
After the description, you can also place your own tags in your own namespace. This allow to provide some custom information about the module.
-
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/ivyauthor.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/ivyauthor.adoc b/asciidoc/ivyfile/ivyauthor.adoc
index 5859711..282c5bc 100644
--- a/asciidoc/ivyfile/ivyauthor.adoc
+++ b/asciidoc/ivyfile/ivyauthor.adoc
@@ -19,7 +19,7 @@
*Tag:* ivyauthor *Parent:* link:../ivyfile/info.html[info]
-Gives information about who has contributed to write this ivy file. It does NOT indicate who
+Gives information about who has contributed to write this ivy file. It does NOT indicate who
is the author of the module itself.
== Attributes
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/manager.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/manager.adoc b/asciidoc/ivyfile/manager.adoc
index a1d6f60..6424373 100644
--- a/asciidoc/ivyfile/manager.adoc
+++ b/asciidoc/ivyfile/manager.adoc
@@ -23,7 +23,11 @@
Specify a a conflict manager for one or several dependencies.
-The way to specify a conflict manager is by giving indication to which dependencies the conflict manager applies (by giving organisation and module names or name regexp), and then specifying the conflict manager, either by giving its name or by specifying a fixed revision list, in which case a fixed conflicts manager is used.
+The way to specify a conflict manager is by giving indication to which dependencies
+the conflict manager applies (by giving organisation and module names or name regexp),
+and then specifying the conflict manager, either by giving its name or by
+specifying a fixed revision list, in which case a fixed conflicts manager is used.
+
See link:../ivyfile/conflicts.html[Conflicts Manager] for details on conflicts manager in general.
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/mapped.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/mapped.adoc b/asciidoc/ivyfile/mapped.adoc
index b7ffa3b..65c6c6b 100644
--- a/asciidoc/ivyfile/mapped.adoc
+++ b/asciidoc/ivyfile/mapped.adoc
@@ -26,7 +26,7 @@ Describes a mapped dependency configuration for a master configuration.
[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
-|name|the name of the dependency configuration mapped.
+|name|the name of the dependency configuration mapped.
`$$*$$` wildcard can be used to designate all configurations of this module|Yes
|=======
http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b02336b7/asciidoc/ivyfile/override.adoc
----------------------------------------------------------------------
diff --git a/asciidoc/ivyfile/override.adoc b/asciidoc/ivyfile/override.adoc
index 86bc79e..38330be 100644
--- a/asciidoc/ivyfile/override.adoc
+++ b/asciidoc/ivyfile/override.adoc
@@ -36,7 +36,7 @@ Note that even though no attribute is required, it makes no sense to set no attr
|Attribute|Description|Required
|org|the name, or an expression matching the name of organisation to which overriding should be applied (see matcher attribute below)|No, defaults to `$$*$$` (match all)
|module|the name, or an expression matching the name of module to which overriding should be applied (see matcher attribute below)|No, defaults to `$$*$$` (match all)
-|branch|the branch to set for all the overriden dependency descriptors|No, by default branch is not overriden
-|rev|the revision to set for all the overriden dependency descriptors|No, by default revision is not overriden
+|branch|the branch to set for all the overridden dependency descriptors|No, by default branch is not overridden
+|rev|the revision to set for all the overridden dependency descriptors|No, by default revision is not overridden
|matcher|the link:../concept.html#matcher[matcher] to use to match the modules for which the conflict manager should be used|No, defaults to `exact`
|=======