You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by ma...@apache.org on 2010/08/31 10:37:51 UTC
svn commit: r991118 [2/2] - in /ant/ivy/core/branches/2.2.x: ./ doc/
doc/resolver/ doc/settings/ doc/tutorial/ doc/tutorial/build-repository/
src/java/org/apache/ivy/core/settings/
src/java/org/apache/ivy/plugins/resolver/ src/java/org/apache/ivy/plugi...
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/dependence.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/dependence.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/dependence.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/dependence.html Tue Aug 31 08:37:50 2010
@@ -25,19 +25,19 @@
</head>
<body>
<textarea id="xooki-source">
-This example is an illustration of dependency between two projects.
+This tutorial will show you how to use Ivy when one of your projects depends on another.
-The depender project declares that it uses the dependee one. We will illustrate two things:
+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:
<ul>
- <li>public libraries declared by standalone project will automatically be retrieved by the dependant project</li>
- <li>the depender project will retrieve the "latest" version of the dependee project</li>
+ <li>that dependencies defined by parent projects (dependee) will automatically be retrieved for use by child projects (depender)</li>
+ <li>that child projects can retrieve the "latest" version of the dependee project</li>
</ul>
<h1>projects used</h1>
<h2>dependee</h2>
-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:
+The dependee project is very simple. It depends on the apache library commons-lang and contains only one class: <tt>standalone.Main</tt> which provides two services:
<ul>
<li>return the version of the project</li>
- <li>capitalize a string using org.apache.commons.lang.WordUtils.capitalizeFully</li>
+ <li>capitalize a string using <tt>org.apache.commons.lang.WordUtils.capitalizeFully</tt></li>
</ul>
Here is the content of the project:
<ul>
@@ -55,14 +55,14 @@ Take a look at the <b>ivy.xml</b> file:
</ivy-module>
</code>
-The ivy dependency file declares only one dependency on apache commons-lang library.
+The ivy file declares only one dependency, that being the apache commons-lang library.
<h2>depender</h2>
-The project depender is very simple too. It declares only one dependency on the latest version of the dependee project and it contains only one class depending.Main which make 2 things:
+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, <tt>depending.Main</tt>, which does 2 things:
<ul>
- <li>getting the version of the standalone project throw a call to standalone.Main.getVersion()</li>
- <li>transform a string throw a call to standalone.Main.capitalizeWords(str)</li>
+ <li>gets the version of the standalone project by calling <tt>standalone.Main.getVersion()</tt></li>
+ <li>transforms a string by calling <tt>standalone.Main.capitalizeWords(str)</tt></li>
</ul>
-Take a look at the <b>ivy.xml</b> file:
+Take a look at the <tt>ivy.xml</tt> file:
<code>
<ivy-module version="1.0">
<info organisation="org.apache" module="depender"/>
@@ -73,13 +73,13 @@ Take a look at the <b>ivy.xml</b> file:
</code>
<h1>settings</h1>
-The ivy settings is made in the settings directory which contains 2 files:
+The Ivy settings are defined in two files located in the settings directory:
<ul>
- <li>ivysettings.properties: a property file</li>
- <li>ivysettings.xml: the file containing the settings</li>
+ <li><tt>ivysettings.properties</tt>: a property file</li>
+ <li><tt>ivysettings.xml</tt>: the file containing the settings</li>
</ul>
-Let's have a look at the ivysettings.xml file:
+Let's have a look at the <tt>ivysettings.xml</tt> file:
<code>
<ivysettings>
<properties file="${ivy.settings.dir}/ivysettings.properties"/>
@@ -98,53 +98,53 @@ Let's have a look at the ivysettings.xml
</code>
The file contains four main tags: properties, settings, resolvers and modules.
<h2>properties</h2>
-This tag only load some properties for the ivy process in the same manner as ant would do it.
+This tag loads some properties for the Ivy process, just like Ant does.
<h2>settings</h2>
-This tag is in charge of initializing some parameters for ivy process. 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 called "libraries" as its default resolver. More information can be found in the [[settings settings reference documentation]].
+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 <tt>ivysettings.xml</tt> file itself.
+The second parameter, tells Ivy to use a resolver named "libraries" as its default resolver. More information can be found in the [[settings settings reference documentation]].
<h2>resolvers</h2>
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 ibiblio resolver called "libraries" is able to find dependencies on maven 2 repository, but doesn't use maven poms.
+The ibiblio resolver called "libraries" is able to find dependencies on the maven 2 repository, but doesn't use maven poms.
<h2>modules</h2>
-The modules tag allows to configure which resolver should be used for which module. Here the settings only tells to use the "projects" resolver for all modules having for organisation "org.apache" and for module name "dependee". This actually corresponds to only one module, but a regular expression could be used, or many other kind of expressions (like glob expressions).
+The modules tag allows you to configure which resolver should be used for which module. Here the setting tells Ivy to use the "projects" resolver for all modules having an organisation of <tt>org.apache</tt> and module name of <tt>dependee</tt>. This actually corresponds to only one module, but a regular expression could be used, or many other types of expressions (like glob expressions).
-For other modules (i.e. all modules but org.apache#dependee), since there is no special settings, the default resolver will be used: "libraries".
+All other modules (i.e. all modules but org.apache#dependee), will use the default resolver ("libraries").
<h1>walkthrough</h1>
<div class="step">
<h2>step 1: preparation</h2>
-Open a DOS or shell window, and go to the "src/example/dependence" directory.
+Open a DOS or shell window, and go to the <tt>src/example/dependence</tt> directory.
</div>
<div class="step">
<h2>step 2: clean directory tree</h2>
-On the prompt type: ant
-This will clean up the entire project directory tree. You can do it each time you want to clean up this example.
+On the prompt type: <tt>ant</tt>
+This will clean up the entire project directory tree. You can do this each time you want to clean up this example.
</div>
<div class="step">
<h2>step 3: publication of dependee project</h2>
-Go to dependee directory and publish the project
+Go to <tt>dependee</tt> directory and publish the project
<div class="shell"><pre>
[<tutorial/log/dependence-standalone.txt>]
</pre></div>
What we see here:
<ul>
<li>the project depends on 1 library (1 artifact)</li>
- <li>the library was not in the ivy cache and so was downloaded (1 downloaded)</li>
+ <li>the library was not in the Ivy cache and so was downloaded (1 downloaded)</li>
<li>the project has been released under version number 1</li>
</ul>
</div>
-To give more details on the publish, as you can see the call to the publish task has resulted in two main things:
+As you can see, the call to the publish task has resulted in two main things:
<ul>
-<li>the delivery of a resolved ivy file to build/ivy.xml.</li>
-This has been done because by default the publish task not only publishes artifacts but also ivy file. So it has looked to the path where the ivy file to publish should be, using the artifactspattern: ${build.dir}/[artifact].[ext].
-For an ivy file, this resolves to build/ivy.xml. Because this file does not exist, it automatically makes a call to the deliver task which delivers a resolved ivy file to this destination.
-<li>the publication of artifact dependee and resolved ivy file to the repository.</li>
-Both are mere copy of files found in the current project, more precisely in the build dir. This is because the artifactspattern has been set to ${build.dir}/[artifact].[ext], so dependee artifact is found in build/dependee.jar and ivy file in build/ivy.xml. And because we have asked the publish task to publish them using the "projects" resolver, these files are copied to repository\dependee-1.jar and to repository\dependee-1.xml, respecting the artifact and ivy patterns of our settings (see above).
+<li>the delivery of a resolved ivy file to <tt>build/ivy.xml</tt>.</li>
+This has been done because by default, the publish task not only publishes artifacts, but also its ivy file. So it has looked to the path where the ivy file to publish should be, using the artifactspattern: <tt>${build.dir}/[artifact].[ext]</tt>. For an ivy file, this resolves to <tt>build/ivy.xml</tt>. Because this file does not exist, it automatically makes a call to the deliver task which delivers a resolved ivy file to this destination.
+
+<li>the publication of artifact 'dependee' and its resolved ivy file to the repository.</li>
+Both are just copies of the files found in the current project, or more precisely, those in the <tt>build</tt> directory. This is because the artifactspattern has been set to <tt>${build.dir}/[artifact].[ext]</tt>, so the dependee artifact is found at <tt>build/dependee.jar</tt> and the ivy file in <tt>build/ivy.xml</tt>. And because we have asked the publish task to publish them using the "projects" resolver, these files are copied to <tt>repository\dependee-1.jar</tt> and to <tt>repository\dependee-1.xml</tt>, respecting the artifact and ivy patterns of our settings (see above).
</ul>
<div class="step">
<h2>step 4: running the depender project</h2>
-Go to directory depender and run ant
+Go to directory depender and run <tt>ant</tt>
<div class="shell"><pre>
[<tutorial/log/dependence-depending.txt>]
</pre></div>
@@ -152,17 +152,17 @@ What we see here:
<ul>
<li>the project depends on 2 libraries (2 artifacts)</li>
<li>one of the libraries was in the cache because there was only 1 download (1 downloaded)</li>
- <li>ivy retrieved the 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 artifact version 1 of the project dependee</li>
- <li>the call to standalone.Main.capitalizeWords(str) succeed, which means that the required library were in the classpath. If you look at the lib directory, you will see that the library commons-lang-2.0.jar was retrieved. This library was declared to be used by the project "dependee", so ivy get it too for the depender project.</li>
+ <li>Ivy retrieved version 1 of the project "dependee". The call to <tt>standalone.Main.getVersion()</tt> has returned 1. If you look in the <tt>depender/lib</tt> directory, you should see <tt>dependee-1.jar</tt> which is the version 1 artifact of the project "dependee"</li>
+ <li>the call to <tt>standalone.Main.capitalizeWords(str)</tt> succeed, which means that the required library was in the classpath. If you look at the <tt>lib</tt> directory, you will see that the library <tt>commons-lang-2.0.jar</tt> was also retrieved. This library was declared as a dependency of the "dependee" project, so Ivy retrieves it (transitively) along with the dependee artifact.</li>
</ul>
</div>
<div class="step">
<h2>step 5: new version of dependee project</h2>
-Like we did before in step 3, publish again the dependee project. This will result as a new version of the project.
+Like we did before in step 3, publish the dependee project again. This will result in a new version of the project being published.
<div class="shell"><pre>
[<tutorial/log/dependence-standalone-2.txt>]
</pre></div>
-Now if you look in your repository folder, you will find 2 version published of the dependee project.
+Now if you look in your repository folder, you will find 2 versions of the dependee project.
Let's look at it:
<div class="shell"><pre>I:\dependee>dir ..\settings\repository /w
@@ -170,19 +170,19 @@ Let's look at it:
I:\dependee></pre></div>
</div>
-Ok now our repository contains two versions of the project <b>dependee</b>, other projects can refer to both versions.
+OK, now our repository contains two versions of the project <b>dependee</b>, so other projects can refer to either version.
<div class="step">
<h2>step 6: get the new version in <em>depender</em> project</h2>
-What do we expect about running again the depender project? Two major things are expected:
+What should we expect if we run the depender project again? It should:
<ul>
- <li>retrieve the version 2 as the latest.integration version of the dependee project</li>
- <li>running the test must display version 2 of dependee project</li>
+ <li>retrieve version 2 as the latest.integration version of the dependee project</li>
+ <li>display version 2 of dependee project</li>
</ul>
-Let's go!!!
+Let's try it!!
<div class="shell"><pre>
[<tutorial/log/dependence-depending-2.txt>]
</pre></div>
-Ok we have the result expected as the run target shows that we are using the version 2 of the main class of dependee project. If we take a look at the resolve target results, we can see that one artifact has been downloaded to the ivy cache. In fact this file is the version 2 of the dependee project that was taken from the repository, you can now retrieve it in the ivy-cache directory.
+OK, we got what we expected as the <tt>run</tt> target shows that we are using version 2 of the main class of the dependee project. If we take a look at the resolve target results, we see that one artifact has been downloaded to the ivy cache. In fact, this file is the same version 2 of the dependee project that is in the repository, but now all future retrievals will pull it from your ivy-cache directory.
</div>
</textarea>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/dual.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/dual.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/dual.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/dual.html Tue Aug 31 08:37:50 2010
@@ -25,21 +25,21 @@
</head>
<body>
<textarea id="xooki-source">
-In some cases it may happen that your module descriptors (Ivy files, maven pom, ...) are located at one place and module artifacts (jars, ...) at another place.
+In some cases, your module descriptions (i.e. Ivy files, maven poms) are located separately from the module artifacts (i.e. jars). So what can you do about it?
-Dual Resolver is used to address this kind of need, and this tutorial will show how to use it.
+Use a Dual resolver! And this tutorial will show you how.
<h1>project description</h1>
-Let's have a look at the src/example/dual directory in your ivy distribution.
+Let's have a look at the <tt>src/example/dual</tt> directory in your Ivy distribution.
It contains a build file and 3 directories:
<ul>
<li>settings: contains the ivy settings file</li>
<li>repository: a sample repository of ivy files</li>
-<li>project: the project making use of ivy with dual resolver</li>
+<li>project: the project making use of Ivy with dual resolver</li>
</ul>
<h2>the dual project</h2>
-The project is very simple and contains only one simple class: example.Hello
+The project is very simple and contains only one simple class: <tt>example.Hello</tt>
It depends on two libraries: Apache commons-lang and Apache commons-httpclient.
Here is the content of the project:
@@ -49,7 +49,7 @@ Here is the content of the project:
<li>src\example\Hello.java: the only class of the project</li>
</ul>
-Let's have a look at the <b>ivy.xml</b> file:
+Let's have a look at the <tt>ivy.xml</tt> file:
<code>
<ivy-module version="1.0">
<info organisation="org.apache" module="hello-ivy"/>
@@ -60,10 +60,10 @@ Let's have a look at the <b>ivy.xml</b>
</ivy-module>
</code>
-As you can see, nothing special here... Indeed, it's the philosophy of ivy to keep ivy files independent of the way dependencies are resolved.
+As you can see, nothing special here... Indeed, Ivy's philosophy is to keep ivy files independent of the way dependencies are resolved.
<h2>the <b>ivy</b> settings</h2>
-The ivy settings is made in the settings directory; it contains only one file: ivysettings.xml.
+The ivy settings are defined in the <tt>ivysettings.xml</tt> file located in the <tt>settings</tt> directory. Here is what it contains, followed by an explanation.
<code>
<ivysettings>
@@ -79,29 +79,30 @@ The ivy settings is made in the settings
</ivysettings>
</code>
-Here we configure one resolver, the default one, which is a dual resolver. This dual resolver has two sub resolvers: the first is what is called the "ivy" or "metadata" resolver of the dual resolver, and the second one is what is called the "artifact" resolver. It is important that the dual resolver exactly has two sub resolvers in this given order.
-The metadata resolver, here a filesystem one, is used only to find module descriptors, in this case Ivy files. The settings given in this resolver says that all ivy files are in the same directory, named like that: [module]-ivy-[revision].xml. If we check the repository directory, we can confirm that it contains a file named commons-httpclient-ivy-2.0.2.xml. It fulfills the given pattern and will thus be found by this resolver.
-The artifact resolver is simply an ibiblio one, configured in m2compatible mode to use the maven 2 repository, with usepoms="false" to make sure it won't use maven 2 metadata. Note that this isn't strictly necessary, since the second resolver in a dual resolver (the artifact resolver) is never asked to find module metadata.
+Here we configured one resolver, the default one, which is a dual resolver. This dual resolver has two sub resolvers: the first is what is called the "ivy" or "metadata" resolver of the dual resolver, and the second one is what is called the "artifact" resolver. It is important that the dual resolver has exactly two sub resolvers in this given order.
+
+The metadata resolver, here a filesystem one, is used only to find module descriptors, in this case Ivy files. The setting shown here tells Ivy that all ivy files are in the <tt>repository</tt> directory, named with the pattern: <tt>[module]-ivy-[revision].xml</tt>. If we check the <tt>repository</tt> directory, we can confirm that it contains a file named <tt>commons-httpclient-ivy-2.0.2.xml</tt>. This file matches the pattern, so it will be found by the resolver.
+
+The artifact resolver is simply an ibiblio one, configured in m2compatible mode to use the maven 2 repository, with <tt>usepoms="false"</tt> to make sure it won't use maven 2 metadata. Note that this isn't necessary, since the second resolver in a dual resolver (the artifact resolver) is never asked to find module metadata.
<h1>walkthrough</h1>
<div class="step">
<h2>step 1 : preparation</h2>
-Open a DOS or shell window, and go to the "dual" directory.
+Open a DOS or shell window, and go to the <tt>dual</tt> directory.
</div>
<div class="step">
<h2>step 2 : clean up</h2>
-On the prompt type : ant<br>
-This will clean up the entire project directory tree (compiled classes and retrieved libs) and ivy cache.
-You can do it each time you want to clean up this example.
+On the prompt type : <tt>ant</tt><br>
+This will clean up the entire project directory tree (compiled classes and retrieved libs) and the Ivy cache. You can run this each time you want to clean up this example.
</div>
<div class="step">
<h2>step 3 : run the project</h2>
-Goto project directory. And simply run <b>ant</b>.
+Go to the project directory. And simply run <tt>ant</tt>.
<div class="shell"><pre>
[<tutorial/log/dual.txt>]
</pre></div></div>
<br/>
-As you can see, ivy not only downloaded commons-lang and commons-httpclient, but also commons-logging. Indeed, commons-logging is a dependency of httpclient, as we can see in the httpclient ivy file found in the repository directory:
+As you can see, Ivy not only downloaded commons-lang and commons-httpclient, but also commons-logging. Indeed, commons-logging is a dependency of httpclient, as we can see in the httpclient ivy file found in the <tt>repository</tt> directory:
<code>
<ivy-module version="1.0">
<info
@@ -116,9 +117,9 @@ As you can see, ivy not only downloaded
</ivy-module>
</code>
<br/>
-So everything worked well, ivy file has been found in the repository directory and artifacts have been downloaded from ibiblio.
+So everything seemed to work. The ivy file was found in the <tt>repository</tt> directory and the artifacts have been downloaded from ibiblio.
-This kind of setup can be useful if you don't want to rely on 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 can lead to very flexible settings addressing most needs.
+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.
For full details about the dual resolver, have a look at the corresponding [[resolver/dual reference documentation]].
</textarea>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/multiple.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/multiple.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/multiple.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/multiple.html Tue Aug 31 08:37:50 2010
@@ -25,28 +25,28 @@
</head>
<body>
<textarea id="xooki-source">
-This example is an illustration of how modules can be retrieved by multiple resolvers. Using multiple resolvers can be useful in many contexts, here are some examples:
+This tutorial is an example of how modules can be retrieved by multiple resolvers. Using multiple resolvers can be useful in many contexts. For example:
<ul>
-<li>separate integration builds from releases</li>
-<li>use a public repository for third party modules and a private one for internal modules</li>
+<li>separating integration builds from releases</li>
+<li>using a public repository for third party modules and a private one for internal modules</li>
<li>use a repository for storing modules which are not accurate in an unmanaged public repository</li>
<li>use a local repository to expose builds made on one developer's station</li>
</ul>
-In Ivy, the use of multiple resolvers is supported by one compound resolver called a chain resolver.
+In Ivy, the use of multiple resolvers is supported by a compound resolver called the chain resolver.
-In our example, we will simply show how to use two resolvers, one on a local repository and one using maven2 repository.
+In our example, we will simply show you how to use two resolvers, one on a local repository and one using the maven2 repository.
<h1>project description</h1>
<h2>the project: chained-resolvers</h2>
The project is very simple and contains only one simple class: example.Hello.
-It depends on two libraries: Apache commons-lang and a little test library (sources are included in jar file). The test library is used by the project to uppercase a string, and commons-lang is used to capitalize the same string.
+It depends on two libraries: Apache's commons-lang and a custom library named test (sources are included in test-1.0jar file). The test library is used by the project to uppercase a string, and commons-lang is used to capitalize the same string.
Here is the content of the project:
<ul>
<li>build.xml: the ant build file for the project</li>
- <li>ivy.xml: the ivy project file</li>
+ <li>ivy.xml: the Ivy project file</li>
<li>src\example\Hello.java: the only class of the project</li>
</ul>
Let's have a look at the <b>ivy.xml</b> file:
@@ -59,10 +59,10 @@ Let's have a look at the <b>ivy.xml</b>
</dependencies>
</ivy-module>
</code>
-As we expect, the ivy file declares to be dependent on the two libraries that the project use: commons-lang and test. Note that we don't specify the organisation for the dependency test, in this case Ivy assumes the same org as the declaring module, ie org.apache in this case.
+As we'd expect, the ivy file declares this module to be dependent on the two libraries it uses: 'commons-lang' and 'test'. Note that we didn't specify the org for the dependency 'test'. When we exclude org, Ivy assumes it is in the same org as the declaring module. (i.e. 'org.apache').
<h2>the <b>ivy settings</b></h2>
-The ivy settings is made in the settings directory it contains only one file: ivysettings.xml.
+The settings are defined in the ivysettings.xml file located in the settings directory of the project. Below are its contents, followed by an explanation of what it's doing.
<code>
<ivysettings>
@@ -78,17 +78,17 @@ The ivy settings is made in the settings
</ivysettings>
</code>
<h2>the <b>settings</b> tag</h2>
-This tag initializes ivy with some parameters. Here only one is used, the name of the resolver to use by default.
+This tag initializes Ivy with some parameters. Here only one parameter is set, the name of the resolver to use by default.
<h2>the <b>resolvers</b> tag</h2>
-Under this tag, we can find the description of the resolvers that ivy will use. In our example, we have only one resolver, called "chain-example", which is quite special as it defines a list (a chain) of resolvers.
-The resolvers put in the chain are :
+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:
<ul>
- <li>libraries : it is a file resolver. This one is configured to look for artifacts in the "repository" sub directory of the directory that contains the ivysettings.xml file.</li>
- <li>ibiblio : this resolver is a special one. It looks in the ibiblio maven repository to retrieve the libraries.</li>
+ <li>libraries : It is a filesystem resolver, so looks at a directory structure to retrieve the artifacts. This one is configured to look in the <tt>repository</tt> sub directory of the directory that contains the <tt>ivysettings.xml</tt> file.</li>
+ <li>ibiblio : It looks in the ibiblio maven repository to retrieve the artifacts.</li>
</ul>
-That's it, we have configured a chain of resolvers!
+That's it, we have just configured a chain of resolvers!
<h1>walkthrough</h1>
<div class="step">
@@ -98,34 +98,34 @@ Open a DOS or shell window, and go to th
<div class="step">
<h2>step 2: clean directory tree</h2>
On the prompt type: ant<br>
-This will clean up the entire project directory tree and ivy cache. You can do it each time you want to clean up this example.
+This will clean up the entire project directory tree and Ivy cache. You can do this each time you want to clean up this example.
<div class="tip">
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 Ivy cache is something you can do with no fear (except performance): it's only a cache, everything can be (and should be) obtained again from repositories. For those coming from maven 2 land, this may sounds strange, but remember that in Ivy, the cache is not a local repository, things are kept cleanly isolated.
+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.
</div>
</div>
<div class="step">
<h2>step 3: run the project</h2>
-Go to chainedresolvers-project directory. And simply run <b>ant</b>.
+Go to <tt>chained-resolvers</tt> project directory. And simply run <tt>ant</tt>.
<div class="shell"><pre>
[<tutorial/log/chained-resolvers.txt>]
</pre></div></div>
-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).
-The run target succeed in using both commons-lang.jar comming from ibiblio repository and test.jar coming from the local repository.
+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.
<h1>Going further</h1>
-This very simple example helps to see how to make a basic setting of two resolvers in a chain. The [[resolver/chain chain resolver's reference documentation]] is available for those who would like to know all the features offered by this resolver.
+This very simple example helps us see how to set up two resolvers in a chain. The [[resolver/chain chain resolver's reference documentation]] is available for those who would like to know all the features offered by this resolver.
-The most interesting things to know that you can try out from this basic example are:
+Below are a few more interesting things worth knowing about chain resolvers. After reading them, go ahead and try tweaking this example using your new wealth of knowledge!
<ul>
-<li>a chain is not limited to two nested resolvers, you can use the number you want</li>
-<li>by setting returnFirst="true", you can have a chain which stops as soon as it has found a result for a given module</li>
-<li>by setting dual="true", the full chain will be used both for module descriptors and artifacts, while with dual="false", the resolver in the chain which found the module descriptor (if any) is also used for artifacts</li>
+<li>a chain is not limited to two nested resolvers, you can use as many as you want</li>
+<li>by setting <tt>returnFirst="true"</tt>, you can have a chain which stops as soon as it has found a result for a given module</li>
+<li>by setting <tt>dual="true"</tt>, the full chain will be used both for module descriptors and artifacts, while setting <tt>dual="false"</tt>, the resolver in the chain which found the module descriptor (if any) is also used for artifacts</li>
</ul>
</textarea>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/multiproject.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/multiproject.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/multiproject.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/multiproject.html Tue Aug 31 08:37:50 2010
@@ -25,9 +25,9 @@
</head>
<body>
<textarea id="xooki-source">
-In the previous tutorial you have seen how to deal with dependencies between two simple projects.
+In the previous tutorial, you saw how to deal with dependencies between two simple projects.
-This tutorial will guide you through the use of ivy in a more complete environment. All the sources of this tutorial are available in src/example/multi-project in ivy distribution.
+This tutorial will guide you through the use of Ivy in a more complete environment. All of the code for this tutorial is available in the <tt>src/example/multi-project</tt> directory of the Ivy distribution.
<h1>Context</h1>
Here is a 10000ft overview of the projects involved in this tutorial:
@@ -51,7 +51,7 @@ Modules in yellow are the modules descri
As you can see, we have here a pretty interesting set of modules with dependencies between each other, each depending on the latest version of the others.
<h1>The example files</h1>
-The sources for this tutorial can be found in src/example/multi-project in the ivy distribution. In this directory, you will find the following files:
+The sources for this tutorial can be found in <tt>src/example/multi-project</tt> in the Ivy distribution. In this directory, you will find the following files:
<ul>
<li>[[svn:src/example/multi-project/build.xml build.xml]]</li>This is a root build file which can be used to call targets on all modules, in the order of their dependencies (ensuring that a module is always built before any module depending on it, for instance)
<li>common
@@ -61,9 +61,9 @@ The sources for this tutorial can be fou
</ul>
</li>
<li>projects</li>
-contains a directory per module, with for each
+contains a directory per module, with each containing:
<ul>
-<li>ivy.xml</li>Ivy file of the module, describing its dependencies upon other modules and / or external modules.
+<li>ivy.xml</li>Ivy file of the module, describing its dependencies upon other modules and/or external modules.
Example:
<code type="xml">
<ivy-module version="1.0">
@@ -86,7 +86,7 @@ Example:
</dependencies>
</ivy-module>
</code>
-<li>build.xml</li>The build file of the project, which consists mainly in an import of the common build file and of a module specific properties file:
+<li>build.xml</li>The build file of the project, which consists mainly of an import of the common build file and of a module specific properties file:
<code type="xml">
<project name="find" default="compile">
<property file="build.properties"/>
@@ -104,9 +104,9 @@ common.dir = ${wkspace.dir}/common
</ul>
</ul>
-Note that this doesn't demonstrate good practice for software development in general, in particular you won't find any unit test in these samples, even if we think unit testing is very important. But this isn't the aim of this tutorial.
+Note that this example doesn't demonstrate many good practices for software development in general, in particular you won't find any unit test in these samples, even if we think unit testing is very important. But this isn't the aim of this tutorial.
-Now that you are a bit more familiar with the structure, let's have a look at the most important part of this example: the common build file. Indeed, as you have seen all modules build files only import the common build file, and defines their dependencies in their ivy files (which you should begin to be familiar with).
+Now that you are a bit more familiar with the structure, let's have a look at the most important part of this example: the common build file. Indeed, as you have seen, all the module's build files only import the common build file, and define their dependencies in their ivy files (which you should begin to be familiar with).
So, here are some aspects of this common build file:
<h2>ivy settings</h2>
@@ -120,8 +120,8 @@ So, here are some aspects of this common
-->
</code>
-This declaration configures ivy only by setting two properties: the location for the local repository and the location for the shared repository. It's the only settings done here, since ivy is configured by default to work in a team environment (see [[tutorial/defaultconf default settings tutorial]] for details about this). For sure in a real environment the shared repository location would rather be in a team shared directory (or in a more complex repository, again see the default settings tutorial to see how to use something really different).
-Commented out you can see how the settings would have been done if the default settings wasn't ok for our purpose.
+This declaration configures Ivy by only setting two properties: the location for the local repository and the location for the shared repository. It's the only settings done here, since Ivy is configured by default to work in a team environment (see [[tutorial/defaultconf default settings tutorial]] for details about this). For sure in a real environment, the shared repository location would rather be in a team shared directory (or in a more complex repository, again see the default settings tutorial to see how to use something really different).
+Commented out you can see how the settings would have been done if the default setting wasn't OK for our purpose.
<h2>resolve dependencies</h2>
<code type="xml">
@@ -133,7 +133,7 @@ Commented out you can see how the settin
<ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" />
</target>
</code>
-You should begin to be familiar with this kind of use of Ivy. We call resolve explicitly to use the ivy file configured (the default would have been fine), and then call retrieve to copy resolved dependencies artifacts from the cache to a local lib directory. The pattern is also used to name the artifacts in the lib dir with their name and extension only (without revision), this is easier to use with an IDE, the IDE configuration won't change when the artifacts version change.
+You should begin to be familiar with using Ivy this way. We call <i>resolve</i> explicitly to use the ivy file configured (the default would have been fine), and then call <i>retrieve</i> to copy resolved dependencies artifacts from the cache to a local lib directory. The pattern is also used to name the artifacts in the lib dir with their name and extension only (without revision), this is easier to use with an IDE, as the IDE configuration won't change when the artifacts version change.
<h2>ivy-new-version</h2>
<code type="xml">
@@ -141,14 +141,14 @@ You should begin to be familiar with thi
<!-- default module version prefix value -->
<property name="module.version.prefix" value="${module.version.target}-dev-b" />
- <!-- asks to ivy an available version number -->
+ <!-- asks Ivy for an available version number -->
<ivy:info file="${ivy.file}" />
<ivy:buildnumber
organisation="${ivy.organisation}" module="${ivy.module}"
revision="${module.version.prefix}" defaultBuildNumber="1" revSep=""/>
</target>
</code>
-This target is used to ask Ivy to find a new version for a module. To get detailed about the module we are dealing with, we use directly the information found in the ivy file using the ivy:info task. Then the [[ant:buildnumber]] task is used to get a new revision, based on a prefix we set with a property, by default it will be 1.0-dev-b (have a look at the default value for module.version.target in the common build properties file). Each module build by this common build file could easily override this by either setting a different module.version.target in its module specific build.properties, or even overriding module.version.prefix. To get the new revision Ivy scans the repository to find the latest available version with the given prefix, and increment this version by 1.
+This target is used to ask Ivy to find a new version for a module. To get details about the module we are dealing with, we pull information out of the ivy file by using the ivy:info task. Then the [[ant:buildnumber]] task is used to get a new revision, based on a prefix we set with a property, by default it will be 1.0-dev-b (have a look at the default value for <tt>module.version.target</tt> in the <tt>common/build.properties</tt> file). Each module built by this common build file could easily override this by either setting a different <tt>module.version.target</tt> in its module specific <tt>build.properties</tt>, or even overriding <tt>module.version.prefix</tt>. To get the new revision, Ivy scans the repository to find the latest available version with the given prefix, and then increments this version by 1.
<h2>publish</h2>
<code type="xml">
@@ -161,7 +161,7 @@ This target is used to ask Ivy to find a
<echo message="project ${ant.project.name} released with version ${version}" />
</target>
</code>
-This target publishes the module in the shared repository, with the revision found in the version property, which is set by other targets (based on ivy-new-version we have seen above). It can be used when a module reaches a specific milestone, or whenever you want the team to benefit from a new version of the module.
+This target publishes the module to the shared repository, with the revision found in the version property, which is set by other targets (based on ivy-new-version we have seen above). It can be used when a module reaches a specific milestone, or whenever you want the team to benefit from a new version of the module.
<h2>publish-local</h2>
<code type="xml">
<target name="publish-local" depends="local-version, jar" description="--> publish this project in the local ivy repository">
@@ -175,14 +175,14 @@ This target publishes the module in the
<echo message="project ${ant.project.name} published locally with version ${version}" />
</target>
</code>
-This is very similar to the publish task, except that this publish the revision in the local repository, which is used only in your environment and doesn't disturb the team. When you change something in a module and want to benefit from the change in another one, you can simply call publish-local in this module, and then your next build of the other module will automatically get this local version.
+This is very similar to the publish task, except that this publishes the revision to the local repository, which is used only in your environment and doesn't disturb the team. When you change something in a module and want to benefit from the change in another one, you can simply call <tt>publish-local</tt> in this module, and then your next build of the other module will automatically get this local version.
<h2>clean-local</h2>
<code type="xml">
<target name="clean-local" description="--> cleans the local repository for the current module">
<delete dir="${ivy.local.default.root}/${ant.project.name}"/>
</target>
</code>
-This target is used when you don't want to use your local version of a module anymore, for example when you release a new version to the whole team, or discard your local changes and want to take advantage of a new version from the team.
+This target is used when you don't want to use your local version of a module anymore. For example, when you release a new version to the whole team, or discard your local changes and want to take advantage of a new version from the team.
<h2>report</h2>
<code type="xml">
<target name="report" depends="resolve" description="--> generates a report of dependencies">
@@ -191,26 +191,26 @@ This target is used when you don't want
</code>
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 [[yed here]] with the graphml file you will find in <code>projects/console/build/</code> after having called report in the console project, and that's it, you have a clear overview of all your app dependencies !
+For example, to generate a graph like the one shown at the beginning of this tutorial, you just have to follow the instructions given [[yed here]] with the graphml file you will find in <code>projects/console/build/</code> after having called report in the console project, and that's it, you have a clear overview of all your app dependencies!
<h1>Playing with the projects</h1>
-To play with this tutorial you can use regular ant commands. Begin in the base directory of the tutorial (src/example/multi-project), and run ant -p:
+You can play with this tutorial by using regular Ant commands. Begin in the base directory of the tutorial (src/example/multi-project), and run ant -p:
<div class="shell"><pre>
[<tutorial/log/multi-project-general-antp.txt>]
</pre></div>
-This gives you an idea of what you can do here. To make sure you have at least one version of all your modules published in your repository (required to build modules having dependencies on the others), you can run ant publish-all (example log <a href="log/multi-project-general-publishall.txt">here</a>).
+This gives you an idea of what you can do here. To make sure you have at least one version of all your modules published in your repository (required to build modules having dependencies on the others), you can run <tt>ant publish-all</tt> (example log <a href="log/multi-project-general-publishall.txt">here</a>).
You will see that Ivy calls the publish target on all the modules, following the order of the dependencies, so that a dependee is always built and published before its depender. Feel free to make changes in the source code of a module (changing a method name for instance) and in the module using the method, then call publish-all to see how the change in the dependee is compiled first, published, and then available to the depender which can compile successfully.
-Then you can go in one of the example project directory (like projects/find for instance), and run ant -p:
+Then you can go in one of the example project directories (like projects/find for instance), and run <tt>ant -p</tt>:
<div class="shell"><pre>
[<tutorial/log/multi-project-find-antp.txt>]
</pre></div>
-You can see the targets available, thanks to the import of the common.xml build file. Pay with the project by calling resolve, publish, and see what happens when you do the same in other projects. An interesting thing to do for instance is to change the dependencies of a project: if the module version now depends on a new commons library, you will see that all other projects depending on version will get this library as part of their transitive dependencies once the new revision of the version project is published. Very easy! And if a project introduces a change with which the depender is incompatible yet, you can very easily change the dependency in the depender to move from latest.integration to a fixed version with which the depender is compatible (probably the latest before the change). Keeping your modules under control is now very easy!
+You can see the targets available, thanks to the import of the <tt>common.xml</tt> build file. Play with the project by calling resolve, and publish, and see what happens when you do the same in other projects. An interesting thing to do for instance, is to change the dependencies of a project. If the module version now depends on a new commons library, you will see that all other projects depending on that version will get this library as part of their transitive dependencies once the new revision of the version project is published. Very easy! And if a project introduces a change with which the depender isn't compatible with yet, you can easily change the dependency in the depender to move from <tt>latest.integration</tt> to a fixed version with which the depender is compatible (probably the latest before the change). Keeping your modules under control is now very easy!
-You should then be pretty familiar with multi project development with Ivy, we hope you will appreciate its power and flexibility! And those tutorials are only the beginning of your journey with Ivy, browse the [[reference reference documentation]] to learn more about the features, subscribe to the [[mailing-lists mailing lists]] to share your experience and ask questions with the community, browse the source code, open jira issues, submit patches, join in and help make Ivy the best dependency management tool!</textarea>
+By now, you should be pretty familiar with multi-project development with Ivy. We hope you will appreciate its power and flexibility! And these tutorials are only the beginning of your journey with Ivy, browse the [[reference reference documentation]] to learn more about the features, subscribe to the [[mailing-lists mailing lists]] to share your experience and ask questions with the community, browse the source code, open jira issues, submit patches, join in and help make Ivy the best of dependency management tools!</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/start.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/start.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/start.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/start.html Tue Aug 31 08:37:50 2010
@@ -25,7 +25,7 @@
</head>
<body>
<textarea id="xooki-source">
-In this example, we will see one of the easiest way 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.
<em>You'll find this tutorial's sources in the ivy distribution in the src/example/hello-ivy directory.</em>
@@ -42,13 +42,13 @@ Here is the sample:
</ivy-module>
</code>
-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 use.
+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 of them.
+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 let 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 attribute to define the organization and module name of the dependencies we need. The rev attribute is used to specify the revision 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 <tt>org</tt> and <tt>name</tt> attributes to define the organization and module name of the dependencies we need. The <tt>rev</tt> 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. We recommend you use <a href="http://mvnrepository.com">mvnrepository.com</a> 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:
+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 <a href="http://mvnrepository.com">mvnrepository.com</a> 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:
<code>
<dependency>
<groupId>commons-lang</groupId>
@@ -60,7 +60,7 @@ To convert this into an Ivy dependency d
If you want more details on what you can do in Ivy files, you can have a look at the [[ivyfile Ivy files reference documentation]].
<h1>The build.xml file</h1>
-The corresponding build file contains a set of targets, allowing to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project.
+The corresponding build file contains a set of targets, allowing you to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project.
You can use the standard "ant -p" to get the list of available targets. Feel free to have a look at the whole file, but here is the part relevant to dependency resolution:
<code type="xml">
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run">
@@ -77,12 +77,12 @@ You can use the standard "ant -p" to get
</code>
As you can see, it's very easy to call Ivy to resolve and retrieve dependencies: all you need if Ivy is properly [[install installed]] is to define an XML namespace in your Ant file (xmlns:ivy="antlib:org.apache.ivy.ant"). Then all the [[ant Ivy ant tasks]] will be available in this namespace.
-Here we use only one task: the [[use/retrieve]] task. With no attributes, it will use default settings and look for a file named ivy.xml for dependency definition. That's exactly what we want, so we need nothing more than that.
+Here we use only one task: the [[use/retrieve]] task. With no attributes, it will use default settings and look for a file named <tt>ivy.xml</tt> for the dependency definitions. That's exactly what we want, so we need nothing more than that.
-Note that in this case we define a "resolve" target and call the [[use/retrieve]] task. This may sound confusing, actually the retrieve task performs a [[use/resolve]] (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of those file in a local project directory). Check the [[principle]] page for details about that.
+Note that in this case we define a <tt>resolve</tt> target and call the <tt>[[use/retrieve]]</tt> task. This may sound confusing, actually the retrieve task performs a [[use/resolve]] (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of those file to a local project directory). Check the [[principle]] page for details about that.
<h1>Running the project</h1>
-Ok, now that we have seen the files involved, let's run the sample to see what happens. Open a shell (or command line) window, and enter the hello-ivy example directory.
-Then, at the command prompt, run 'ant':
+OK, now that we have seen the files involved, let's run the sample to see what happens. Open a shell (or command line) window, and enter the <tt>hello-ivy</tt> example directory.
+Then, at the command prompt, run <tt>ant</tt>:
<div class="shell"><pre>
[<tutorial/log/hello-ivy-1.txt>]
</pre></div>
@@ -90,11 +90,11 @@ Then, at the command prompt, run 'ant':
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 [[use/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:
+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:
<div class="shell"><pre>
[<tutorial/log/hello-ivy-2.txt>]
</pre></div>
-Great! the cache was used, no download was needed and the build was instantaneous.
+Great! The cache was used, so no download was needed and the build was instantaneous.
And now, if you want to generate a report detailing all the dependencies of your module, you can call the report target, and check the generated file in the build directory. You should obtain something looking like <a href="../samples/apache-hello-ivy-default.html">this</a>.
Modified: ant/ivy/core/branches/2.2.x/ivy.xml
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/ivy.xml?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/ivy.xml (original)
+++ ant/ivy/core/branches/2.2.x/ivy.xml Tue Aug 31 08:37:50 2010
@@ -50,6 +50,7 @@
<dependency org="oro" name="oro" rev="2.0.8" conf="default,oro->default"/>
<dependency org="commons-vfs" name="commons-vfs" rev="1.0" conf="default,vfs->default" />
<dependency org="com.jcraft" name="jsch" rev="0.1.31" conf="default,sftp->default" />
+ <dependency org="org.bouncycastle" name="bcpg-jdk14" rev="1.45" conf="default" />
<!-- Test dependencies -->
<dependency org="junit" name="junit" rev="3.8.2" conf="test->default" />
Modified: ant/ivy/core/branches/2.2.x/ivysettings-release.xml
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/ivysettings-release.xml?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/ivysettings-release.xml (original)
+++ ant/ivy/core/branches/2.2.x/ivysettings-release.xml Tue Aug 31 08:37:50 2010
@@ -17,8 +17,13 @@
under the License.
-->
<ivysettings>
- <property name="upload.url" value="https://repository.apache.org/service/local/staging/deploy/maven2"/>
+ <property name="upload.url" value="https://repository.apache.org/service/local/staging/deploy/maven2" />
+ <property name="pgp.keyId" value="auto" override="false" />
<credentials host="repository.apache.org" realm="Sonatype Nexus Repository Manager" username="${upload.user}" passwd="${upload.password}"/>
+
+ <signers>
+ <pgp name="apache-sig" secring="${user.home}/.gnupg/secring.gpg" password="${pgp.password}" keyId="${pgp.keyId}"/>
+ </signers>
<settings defaultResolver="default" />
<resolvers>
@@ -26,7 +31,7 @@
<ibiblio name="public" m2compatible="true" />
<ibiblio name="snapshot" m2compatible="true" root="http://people.apache.org/repo/m2-snapshot-repository" />
</chain>
- <url name="nexus" m2compatible="true" checksums="">
+ <url name="nexus" m2compatible="true" signer="apache-sig">
<artifact pattern="${upload.url}/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" />
</url>
</resolvers>
Modified: ant/ivy/core/branches/2.2.x/optional.patterns
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/optional.patterns?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/optional.patterns (original)
+++ ant/ivy/core/branches/2.2.x/optional.patterns Tue Aug 31 08:37:50 2010
@@ -30,6 +30,7 @@ org/apache/ivy/plugins/resolver/SshResol
org/apache/ivy/plugins/resolver/VfsResolver.java
org/apache/ivy/plugins/resolver/VsftpResolver.java
org/apache/ivy/plugins/resolver/packager/*.java
+org/apache/ivy/plugins/signer/bouncycastle/**/*.java
org/apache/ivy/util/url/HttpClientHandler.java
#This section defines the resources to copy for ivy-optional.jar
Modified: ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/IvySettings.java
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/IvySettings.java?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/IvySettings.java (original)
+++ ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/IvySettings.java Tue Aug 31 08:37:50 2010
@@ -92,6 +92,7 @@ import org.apache.ivy.plugins.resolver.C
import org.apache.ivy.plugins.resolver.DependencyResolver;
import org.apache.ivy.plugins.resolver.DualResolver;
import org.apache.ivy.plugins.resolver.ResolverSettings;
+import org.apache.ivy.plugins.signer.SignatureGenerator;
import org.apache.ivy.plugins.trigger.Trigger;
import org.apache.ivy.plugins.version.ChainVersionMatcher;
import org.apache.ivy.plugins.version.ExactVersionMatcher;
@@ -155,6 +156,9 @@ public class IvySettings implements Sort
// Map (String name -> RepositoryCacheManager)
private Map repositoryCacheManagers = new HashMap();
+
+ // Map (String name -> SignatureGenerator)
+ private Map signatureGenerators = new HashMap();
// List (Trigger)
private List triggers = new ArrayList();
@@ -684,6 +688,19 @@ public class IvySettings implements Sort
public void addConfigured(ModuleDescriptorParser parser) {
ModuleDescriptorParserRegistry.getInstance().addParser(parser);
}
+
+ public void addConfigured(SignatureGenerator generator) {
+ addSignatureGenerator(generator);
+ }
+
+ public void addSignatureGenerator(SignatureGenerator generator) {
+ init(generator);
+ signatureGenerators.put(generator.getName(), generator);
+ }
+
+ public SignatureGenerator getSignatureGenerator(String name) {
+ return (SignatureGenerator) signatureGenerators.get(name);
+ }
public void addResolver(DependencyResolver resolver) {
if (resolver == null) {
Modified: ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/XmlSettingsParser.java
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/XmlSettingsParser.java?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/XmlSettingsParser.java (original)
+++ ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/XmlSettingsParser.java Tue Aug 31 08:37:50 2010
@@ -107,7 +107,7 @@ public class XmlSettingsParser extends D
private List configuratorTags = Arrays.asList(new String[] {"resolvers", "namespaces",
"parsers", "latest-strategies", "conflict-managers", "outputters", "version-matchers",
"statuses", "circular-dependency-strategies", "triggers", "lock-strategies",
- "caches"});
+ "caches", "signers"});
private IvySettings ivy;
Modified: ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/typedef.properties
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/typedef.properties?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/typedef.properties (original)
+++ ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/typedef.properties Tue Aug 31 08:37:50 2010
@@ -54,4 +54,6 @@ ant-build = org.apache.ivy.ant.AntBuild
ant-call = org.apache.ivy.ant.AntCallTrigger
log = org.apache.ivy.plugins.trigger.LogTrigger
-cache = org.apache.ivy.core.cache.DefaultRepositoryCacheManager
\ No newline at end of file
+cache = org.apache.ivy.core.cache.DefaultRepositoryCacheManager
+
+pgp = org.apache.ivy.plugins.signer.bouncycastle.OpenPGPSignatureGenerator
\ No newline at end of file
Modified: ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java (original)
+++ ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java Tue Aug 31 08:37:50 2010
@@ -45,6 +45,7 @@ import org.apache.ivy.plugins.repository
import org.apache.ivy.plugins.resolver.util.ResolvedResource;
import org.apache.ivy.plugins.resolver.util.ResolverHelper;
import org.apache.ivy.plugins.resolver.util.ResourceMDParser;
+import org.apache.ivy.plugins.signer.SignatureGenerator;
import org.apache.ivy.plugins.version.VersionMatcher;
import org.apache.ivy.util.ChecksumHelper;
import org.apache.ivy.util.FileUtil;
@@ -58,6 +59,8 @@ public class RepositoryResolver extends
private Repository repository;
private Boolean alwaysCheckExactRevision = null;
+
+ private String signerName = null;
public RepositoryResolver() {
}
@@ -76,6 +79,10 @@ public class RepositoryResolver extends
((AbstractRepository) repository).setName(name);
}
}
+
+ public void setSigner(String signerName) {
+ this.signerName = signerName;
+ }
protected ResolvedResource findResourceUsingPattern(ModuleRevisionId mrid, String pattern,
Artifact artifact, ResourceMDParser rmdparser, Date date) {
@@ -223,11 +230,15 @@ public class RepositoryResolver extends
throw new IllegalArgumentException("Unknown checksum algorithm: " + checksums[i]);
}
}
-
+
repository.put(artifact, src, dest, overwrite);
for (int i = 0; i < checksums.length; i++) {
putChecksum(artifact, src, dest, overwrite, checksums[i]);
}
+
+ if (signerName != null) {
+ putSignature(artifact, src, dest, overwrite);
+ }
}
protected void putChecksum(Artifact artifact, File src, String dest, boolean overwrite,
@@ -243,6 +254,25 @@ public class RepositoryResolver extends
}
}
+ protected void putSignature(Artifact artifact, File src, String dest, boolean overwrite) throws IOException {
+ SignatureGenerator gen = getSettings().getSignatureGenerator(signerName);
+ if (gen == null) {
+ throw new IllegalArgumentException("Couldn't sign the artifacts! " +
+ "Unknown signer name: '" + signerName + "'");
+ }
+
+ File tempFile = File.createTempFile("ivytemp", gen.getExtension());
+
+ try {
+ gen.sign(src, tempFile);
+ repository.put(DefaultArtifact.cloneWithAnotherTypeAndExt(artifact,
+ gen.getExtension(), artifact.getExt() + "." + gen.getExtension()),
+ tempFile, dest + "." + gen.getExtension(), overwrite);
+ } finally {
+ tempFile.delete();
+ }
+ }
+
public DownloadReport download(Artifact[] artifacts, DownloadOptions options) {
EventManager eventManager = getEventManager();
try {
Modified: ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/ResolverSettings.java
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/ResolverSettings.java?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/ResolverSettings.java (original)
+++ ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/ResolverSettings.java Tue Aug 31 08:37:50 2010
@@ -24,6 +24,7 @@ import org.apache.ivy.core.module.id.Mod
import org.apache.ivy.plugins.latest.LatestStrategy;
import org.apache.ivy.plugins.namespace.Namespace;
import org.apache.ivy.plugins.parser.ParserSettings;
+import org.apache.ivy.plugins.signer.SignatureGenerator;
import org.apache.ivy.plugins.version.VersionMatcher;
public interface ResolverSettings extends ParserSettings {
@@ -51,5 +52,7 @@ public interface ResolverSettings extend
String getResolveMode(ModuleId moduleId);
void filterIgnore(Collection names);
+
+ SignatureGenerator getSignatureGenerator(String name);
}