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 [1/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...
Author: maartenc
Date: Tue Aug 31 08:37:50 2010
New Revision: 991118
URL: http://svn.apache.org/viewvc?rev=991118&view=rev
Log:
Merged revisions 990621, 991108 and 991115 from trunk into 2.2.x branch.
Added:
ant/ivy/core/branches/2.2.x/doc/settings/signers.html
- copied unchanged from r991115, ant/ivy/core/trunk/doc/settings/signers.html
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/signer/
- copied from r991115, ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/signer/
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/signer/SignatureGenerator.java
- copied unchanged from r991115, ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/signer/SignatureGenerator.java
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/signer/bouncycastle/
- copied from r991115, ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/signer/bouncycastle/
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/signer/bouncycastle/OpenPGPSignatureGenerator.java
- copied unchanged from r991115, ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/signer/bouncycastle/OpenPGPSignatureGenerator.java
Modified:
ant/ivy/core/branches/2.2.x/ (props changed)
ant/ivy/core/branches/2.2.x/CHANGES.txt
ant/ivy/core/branches/2.2.x/README
ant/ivy/core/branches/2.2.x/build-release.xml
ant/ivy/core/branches/2.2.x/doc/moreexamples.html
ant/ivy/core/branches/2.2.x/doc/resolver/filesystem.html
ant/ivy/core/branches/2.2.x/doc/resolver/ibiblio.html
ant/ivy/core/branches/2.2.x/doc/resolver/sftp.html
ant/ivy/core/branches/2.2.x/doc/resolver/ssh.html
ant/ivy/core/branches/2.2.x/doc/resolver/url.html
ant/ivy/core/branches/2.2.x/doc/settings/resolvers.html
ant/ivy/core/branches/2.2.x/doc/toc.json
ant/ivy/core/branches/2.2.x/doc/tutorial.html
ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository.html
ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/advanced.html
ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/basic.html
ant/ivy/core/branches/2.2.x/doc/tutorial/conf.html
ant/ivy/core/branches/2.2.x/doc/tutorial/defaultconf.html
ant/ivy/core/branches/2.2.x/doc/tutorial/dependence.html
ant/ivy/core/branches/2.2.x/doc/tutorial/dual.html
ant/ivy/core/branches/2.2.x/doc/tutorial/multiple.html
ant/ivy/core/branches/2.2.x/doc/tutorial/multiproject.html
ant/ivy/core/branches/2.2.x/doc/tutorial/start.html
ant/ivy/core/branches/2.2.x/ivy.xml
ant/ivy/core/branches/2.2.x/ivysettings-release.xml
ant/ivy/core/branches/2.2.x/optional.patterns
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/IvySettings.java
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/XmlSettingsParser.java
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/core/settings/typedef.properties
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java
ant/ivy/core/branches/2.2.x/src/java/org/apache/ivy/plugins/resolver/ResolverSettings.java
Propchange: ant/ivy/core/branches/2.2.x/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Aug 31 08:37:50 2010
@@ -1,4 +1,4 @@
/ant/ivy/core/branches/2.0.0:727187-727188,727520-732505
/ant/ivy/core/branches/2.0.0-rc2:707459-708717
/ant/ivy/core/branches/2.0.x:696803-698317
-/ant/ivy/core/trunk:695737,696014-696031,696442,958415-958693,961017-961020,962767-983820,983827-984586,984952,988337,988678,988691-988707
+/ant/ivy/core/trunk:695737,696014-696031,696442,958415-958693,961017-961020,962767-983820,983827-984586,984952,988337,988678,988691-988707,990621-991115
Modified: ant/ivy/core/branches/2.2.x/CHANGES.txt
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/CHANGES.txt?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/CHANGES.txt (original)
+++ ant/ivy/core/branches/2.2.x/CHANGES.txt Tue Aug 31 08:37:50 2010
@@ -113,6 +113,9 @@ for detailed view of each issue, please
=====================================
- DOCUMENTATION: Added missing documentation about the ivy:publish child elements.
- DOCUMENTATION: Grammar, spelling, and clarity of Settings File documentation (IVY-1216) (thanks to Steve Miller)
+- DOCUMENTATION: Grammar, spelling, and clarity of Tutorial documentation (IVY-1222) (thanks to Steve Miller)
+
+- NEW: Ivy can now generate OpenPGP compatible ASCII armored detached signatures when publishing artifacts.
- IMPROVEMENT: the <artifact> child of ivy:publish now accepts any attribute
- IMPROVEMENT: Handle attributes in description subelements (IVY-1214) (thanks to Jean-Louis Boudart)
Modified: ant/ivy/core/branches/2.2.x/README
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/README?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/README (original)
+++ ant/ivy/core/branches/2.2.x/README Tue Aug 31 08:37:50 2010
@@ -53,9 +53,11 @@ code and source code.
The following provides more details on the included cryptographic
software:
-For the Ivy ssh resolver requires the JSch
-<http://www.jcraft.com/jsch/index.html> library.
+The Ivy ssh resolver requires the JSch library
+<http://www.jcraft.com/jsch/index.html>.
The sftp and https resolvers requires the Java Cryptography extensions
<http://java.sun.com/javase/technologies/security/>.
+The PGP signature generator requires the BouncyCastle Java cryptography APIs
+<http://www.bouncycastle.org/java.html>.
Modified: ant/ivy/core/branches/2.2.x/build-release.xml
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/build-release.xml?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/build-release.xml (original)
+++ ant/ivy/core/branches/2.2.x/build-release.xml Tue Aug 31 08:37:50 2010
@@ -18,6 +18,7 @@
-->
<project name="IvyRelease" default="snapshot"
xmlns:ivy="antlib:org.apache.ivy.ant"
+ xmlns:ivy2="antlib:org.apache.ivy.ant_2"
xmlns:xooki="antlib:xooki"
xmlns:openpgp="antlib:org.apache.commons.openpgp.ant">
<import file="build.xml"/>
@@ -469,10 +470,20 @@
</fail>
</target>
- <target name="upload-nexus" depends="release-version, init-ivy">
- <ivy:settings id="upload.settingsId" file="ivysettings-release.xml" />
- <ivy:resolve file="${basedir}/build/artifact/ivy.xml" transitive="false" />
- <ivy:publish organisation="org.apache.ivy"
+ <target name="upload-nexus" depends="release-version, init-ivy, jar">
+ <ivy:retrieve conf="default" pattern="${build.dir}/lib/[artifact]-[revision].[ext]" />
+
+ <taskdef resource="org/apache/ivy/ant/antlib.xml"
+ uri="antlib:org.apache.ivy.ant_2">
+ <classpath>
+ <fileset dir="${artifacts.build.dir}/jars" includes="${final.name}" />
+ <fileset dir="${build.dir}/lib" excludes="ant-*.jar" />
+ </classpath>
+ </taskdef>
+
+ <ivy2:settings id="upload.settingsId" file="ivysettings-release.xml" />
+ <ivy2:resolve file="${basedir}/build/artifact/ivy.xml" transitive="false" />
+ <ivy2:publish organisation="org.apache.ivy"
module="ivy"
revision="${build.version}"
srcivypattern="${basedir}/build/artifact/ivy.xml"
@@ -485,25 +496,7 @@
<artifact name="ivy" ext="pom" type="ivy" />
<artifact name="ivy" ext="jar" type="sources" classifier="sources" />
<artifact name="ivy" ext="jar" type="javadoc" classifier="javadoc" />
-
- <!-- The PGP signatures -->
- <artifact name="ivy" ext="pom.asc" type="asc" />
- <artifact name="ivy" ext="jar.asc" type="asc" />
- <artifact name="ivy" ext="jar.asc" type="asc" classifier="sources" />
- <artifact name="ivy" ext="jar.asc" type="asc" classifier="javadoc" />
-
- <!-- The SHA1 checksums -->
- <artifact name="ivy" ext="pom.sha1" type="sha1" />
- <artifact name="ivy" ext="jar.sha1" type="sha1" />
- <artifact name="ivy" ext="jar.sha1" type="sha1" classifier="sources" />
- <artifact name="ivy" ext="jar.sha1" type="sha1" classifier="javadoc" />
-
- <!-- The MD5 checksums -->
- <artifact name="ivy" ext="pom.md5" type="md5" />
- <artifact name="ivy" ext="jar.md5" type="md5" />
- <artifact name="ivy" ext="jar.md5" type="md5" classifier="sources" />
- <artifact name="ivy" ext="jar.md5" type="md5" classifier="javadoc" />
- </ivy:publish>
+ </ivy2:publish>
</target>
<target name="prepare-snapshot"
Modified: ant/ivy/core/branches/2.2.x/doc/moreexamples.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/moreexamples.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/moreexamples.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/moreexamples.html Tue Aug 31 08:37:50 2010
@@ -25,21 +25,21 @@
</head>
<body>
<textarea id="xooki-source">
-If you have successfully followed and understood all the tutorials, maybe you still need to get a better picture of how to use Ivy in the real world.
+If you have successfully followed and understood all the tutorials, you still might need to get a better picture of how to use Ivy in the real world.
-Here are some links which can be interesting:
+Here are some links which might be interesting:
<h3><a href="http://wiki.hippo.nl/display/OS/SAnt+build+system">SAnt</a></h3>
-SAnt is an experimental build system based on Ant and Ivy. It can be interesting to use as is or to get insight on an interesting approach to manage your builds.
+SAnt is an experimental build system based on Ant and Ivy. It can be interesting to use "as is", or to get insight on an interesting approach to manage your builds.
<h3><a href="https://springmodules.dev.java.net/">Spring Modules</a></h3>
-The spring modules project build system is based on Ant and Ivy, and it's really interesting to have a look at how a modularized project can take advantage of advanced ant and ivy features to make the build simpler.
+The spring modules project build system is based on Ant and Ivy, and it's really interesting to have a look at how a modularized project can take advantage of advanced Ant and Ivy features to make the build simpler.
<h3><a href="http://www.opensymphony.com/webwork/">Webwork</a></h3>
-The webwork project (which should become struts action framework) uses ant+ivy for their build, and thus make their framework very easy to use in an ant+ivy build system. They have a <a href="http://wiki.opensymphony.com/display/WW/Dependencies">page documenting how to use ivy with their framework</a>, which can be an interesting reading even if you don't plan to use webwork.
+The webwork project (which should become struts action framework) uses ant+ivy for their build, and thus makes their framework very easy to use in an ant+ivy build system. They have a <a href="http://wiki.opensymphony.com/display/WW/Dependencies">page documenting how to use Ivy with their framework</a>, which can be an interesting reading, even if you don't plan to use webwork.
-<h3><a href="http://www.jayasoft.org/ivy/doc/articles/ease-multi-module.html">Easing multi module development</a></h3>
-Johan stuyts, the author of SAnt, also contributed a nice article on his view of how to use Ivy on a multi module environment.
+<h3><a href="http://www.jaya.free.fr/ivy/doc/articles/ease-multi-module.html">Easing multi-module development</a></h3>
+Johan stuyts, the author of SAnt, also contributed a nice article on his view of how to use Ivy on a multi-module environment.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
Modified: ant/ivy/core/branches/2.2.x/doc/resolver/filesystem.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/resolver/filesystem.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/resolver/filesystem.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/resolver/filesystem.html Tue Aug 31 08:37:50 2010
@@ -30,15 +30,15 @@
<tr><td class="title">Handle publish</td><td class="value">yes</td></tr>
</table><br/>
-<span class="tagdoc" id="ivysettings.resolvers.filesystem">This resolver uses the file system to resolve ivy files and artifacts.</span> It presents the advantage to usually have very good performances. Moreover, it is easy to setup using basic OS file sharing mechanism.
+<span class="tagdoc" id="ivysettings.resolvers.filesystem">This resolver uses the file system to resolve ivy files and artifacts.</span> An advantage of this resolver is that it usually provides very good performance. Moreover, it is easy to setup using basic OS file sharing mechanisms.
-The configuration of such a resolver is mainly done through ivy and artifact patterns, indicating where ivy files and artifacts can be found in the file system. These patterns must be absolute paths (<span class="since">since 2.0</span>). You can indicate a list of pattern which will be checked one after the other.
+The configuration of such a resolver is mainly done through ivy and artifact patterns, indicating where ivy files and artifacts can be found in the file system. These patterns must be absolute paths (<span class="since">since 2.0</span>). You can indicate a list of patterns which will be checked one after the other.
-<span class="since">since 1.3</span> Using the m2compatible attribute, this resolver will convert dots found in organisation in slashes like maven2 does for groupId. For instance, it will transform the organisation from 'com.company' into 'com/company' when replacing the token [organisation] in your pattern.
+<span class="since">since 1.3</span> Using the m2compatible attribute, this resolver will convert dots found in organisation into slashes like maven2 does for groupId. For instance, it will transform the organisation from 'com.company' into 'com/company' when replacing the token [organisation] in your pattern.
<strong>Limitation</strong>: in m2compatible mode, this resolver is not able list available organizations. It means some features like [[ant:repreport]] are not available.
<h2>Atomic publish support</h2>
-<span class="since">since 2.0</span> This resolver supports atomic publish, which is very suitable for environments with a lot of concurrent publish and resolve. The atomic publish relies on the atomicity of the rename operation in the underlying filesystem (which includes NTFS and POSIX based filesystems).
+<span class="since">since 2.0</span> This resolver supports atomic publish, which is useful for environments with a lot of concurrent publish and resolve actions. The atomic publish relies on the atomicity of the rename operation in the underlying filesystem (which includes NTFS and POSIX based filesystems).
In this case the resolver starts by publishing the module according to the pattern, but where a '.part' suffix is appended to the revision. Then the publish is committed with a rename to the final location.
<b>Limitations</b>
Modified: ant/ivy/core/branches/2.2.x/doc/resolver/ibiblio.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/resolver/ibiblio.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/resolver/ibiblio.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/resolver/ibiblio.html Tue Aug 31 08:37:50 2010
@@ -32,16 +32,16 @@
<span class="tagdoc" id="ivysettings.resolvers.ibiblio">This resolver usually uses ibiblio to find artifacts. </span>
-<span class="since">since 1.3</span> Using the m2compatible attribute, you can benefit from maven 2 repository compatibility (convert dots in organisation in slashes, search for poms, use transitive dependencies of poms). This setting also affects the default place where the resolver look for its artifacts to point to the maven2 repository. So setting this attribute to true is sufficient to use maven 2 ibiblio repository.
+<span class="since">since 1.3</span> Using the m2compatible attribute, you can benefit from maven 2 repository compatibility (convert dots in organisation into slashes, search for poms, use transitive dependencies of poms). This setting also affects the default place where the resolver looks for its artifacts to point to the maven2 repository. So setting this attribute to true is sufficient to use maven 2 ibiblio repository.
-<span class="since">since 1.4</span> When using the m2compatible flag, you can disable the use of poms by setting the usepoms flag to false. It is then roughly equivalent to an url resolver configured like this:
+<span class="since">since 1.4</span> When using the m2compatible flag, you can disable the use of poms by setting the usepoms flag to false. It is then roughly equivalent to a url resolver configured like this:
<code type="xml">
<url name="test" m2compatible="true">
<artifact pattern="http://repo1.maven.org/maven2/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
</url>
</code>
-<span class="since">since 2.0</span> When used in m2compatible mode with the default pattern, this resolver uses maven-metadata.xml files if present to list the revisions available on the repository. This is especially useful when using a maven specific proxy, which does not serve directory listing. This can be disable by using the useMavenMetadata flag.
+<span class="since">since 2.0</span> When used in m2compatible mode with the default pattern, this resolver uses maven-metadata.xml files (if present) to list the revisions available on the repository. This is especially useful when using a maven specific proxy, which does not serve directory listing. This can be disabled by using the useMavenMetadata flag.
<strong>Limitation</strong>: in m2compatible mode, this resolver is not able list available organizations. It means some features like [[ant:repreport]] are not available.
@@ -75,7 +75,7 @@ Defines a resolver called "maven2" using
<code type="xml">
<ibiblio name="maven" m2compatible="true" usepoms="false"/>
</code>
-Same as above, but don't use poms, only artifacts.</textarea>
+Same as above, but doesn't use poms, only artifacts.</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>
Modified: ant/ivy/core/branches/2.2.x/doc/resolver/sftp.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/resolver/sftp.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/resolver/sftp.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/resolver/sftp.html Tue Aug 31 08:37:50 2010
@@ -31,7 +31,7 @@
</table>
<br/>
-<span class="tagdoc" id="ivysettings.resolvers.sftp">This resolver can be used when your ivy repository is located on a server accessible via sftp.</span> The secured nature of sftp and its wide spread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. <span class="since">since 1.4</span>
+<span class="tagdoc" id="ivysettings.resolvers.sftp">This resolver can be used when your ivy repository is located on a server accessible via sftp.</span> The secured nature of sftp and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. <span class="since">since 1.4</span>
If your server supports ssh but not sftp, there is also an <a href="../resolver/ssh.html">ssh resolver</a>.
Modified: ant/ivy/core/branches/2.2.x/doc/resolver/ssh.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/resolver/ssh.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/resolver/ssh.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/resolver/ssh.html Tue Aug 31 08:37:50 2010
@@ -31,7 +31,7 @@
</table>
<br/>
-<span class="tagdoc" id="ivysettings.resolvers.ssh">This resolver can be used when your ivy repository is located on a server accessible via ssh.</span> The secured nature of ssh and its wide spread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. <span class="since">since 1.4</span>
+<span class="tagdoc" id="ivysettings.resolvers.ssh">This resolver can be used when your ivy repository is located on a server accessible via ssh.</span> The secured nature of ssh and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment. <span class="since">since 1.4</span>
If your server supports sftp, you can consider using the <a href="../resolver/sftp.html">sftp resolver</a>.
Modified: ant/ivy/core/branches/2.2.x/doc/resolver/url.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/resolver/url.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/resolver/url.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/resolver/url.html Tue Aug 31 08:37:50 2010
@@ -31,7 +31,7 @@
</table>
<br/>
-<span class="tagdoc" id="ivysettings.resolvers.url">This resolver is one of the most generic, in fact most of the previous resolvers can be obtained by a particular configuration of this one.</span> Indeed it uses urls to find ivy files and artifacts. The urls it uses are defined through ivy and artifact children, each giving a pattern to find ivy files or artifacts.
+<span class="tagdoc" id="ivysettings.resolvers.url">This resolver is one of the most generic. In fact, most of the previous resolvers can be obtained by a particular configuration of this one.</span> Indeed it uses urls to find ivy files and artifacts. The urls it uses are defined through ivy and artifact children, each giving a pattern to find ivy files or artifacts.
<strong>Limitation</strong>: in m2compatible mode, this resolver is not able list available organizations. It means some features like [[ant:repreport]] are not available.
Modified: ant/ivy/core/branches/2.2.x/doc/settings/resolvers.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/settings/resolvers.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/settings/resolvers.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/settings/resolvers.html Tue Aug 31 08:37:50 2010
@@ -169,6 +169,11 @@ By using such a resolver at the beginnin
<td>No</td>
<td>Yes</td>
</tr>
+ <tr><td>signer</td><td>The name of the [[settings/signers detached signature generator]] to use when publishing artifacts. <span class="since">(since 2.2)</span></td>
+ <td>No, by default published artifacts will not get signed by Ivy.</td>
+ <td>No</td>
+ <td>Yes</td>
+ </tr>
</tbody>
</table>
Modified: ant/ivy/core/branches/2.2.x/doc/toc.json
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/toc.json?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/toc.json (original)
+++ ant/ivy/core/branches/2.2.x/doc/toc.json Tue Aug 31 08:37:50 2010
@@ -200,6 +200,13 @@
]
},
{
+ "id":"settings/signers",
+ "title":"signers",
+ "children": [
+
+ ]
+ },
+ {
"id":"settings/lock-strategies",
"title":"lock-strategies",
"children": [
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial.html Tue Aug 31 08:37:50 2010
@@ -25,36 +25,37 @@
</head>
<body>
<textarea id="xooki-source">
-The best way to learn is to practice! That's what the ivy tutorials will help you to do, to discover some of the great ivy [[features features]].
+The best way to learn is to practice! That's what the Ivy tutorials will help you to do, to discover some of the great Ivy [[features features]].
-Here is the very first tutorial, it doesn't even require to install Ivy, and should not take more than 30 seconds if you already have ant and a jdk properly installed:
-<ul>
-<li>make sure you have <a href="http://ant.apache.org/">ant</a> 1.6.0 or greater and a <a href="http://java.sun.com">jdk</a> properly installed</li>
-<li>copy <a href="samples/build.xml">this build file</a> in an empty directory on your local filesystem (and make sure you name it build.xml)</li>
-<li>open a console in this directory and run "ant". That's it!</li>
-</ul>
-If you have any trouble, check the <a href="../../faq.html">FAQ</a>, it may be related to your internet connection (proxy anyone?).
+For the first tutorial you won't even have to install Ivy (assuming you have Ant and a JDK properly installed), and it shouldn't take more than 30 seconds.
+
+<b>First Tutorial</b>
+<ol>
+<li>Make sure you have <a href="http://ant.apache.org/">ant</a> 1.6.0 or greater and a <a href="http://java.sun.com">jdk</a> properly installed</li>
+<li>Copy <a href="samples/build.xml">this build file</a> in an empty directory on your local filesystem (and make sure you name it build.xml)</li>
+<li>Open a console in this directory and run "ant". That's it!</li>
+</ol>
+If you have any trouble, check the <a href="../../faq.html">FAQ</a>. It is most likely related to your internet connection (proxy anyone?).
-OK, you've seen how easy it is to make your first step with ivy? Go ahead with the other tutorials, but before make sure you have properly <a href="install.html">installed</a> ivy and downloaded the tutorials sources (included in all ivy distributions, in the [[svn:src/example]] directory).
+OK, you've just seen how easy it is to take your first step with Ivy. Go ahead with the other tutorials, but before you do, make sure you have properly <a href="install.html">installed</a> Ivy and downloaded the tutorials sources (included in all Ivy distributions, in the <tt>[[svn:src/example]]</tt> directory).
The following tutorials are available:
<ul>
<li><a href="tutorial/start.html">Quick Start</a></li>
-guide you through your very first steps with ivy.
+Guides you through your very first steps with ivy.
<li>[[tutorial/defaultconf]]</li>
-give you a better understanding of the default settings and show you how to customize them to your needs.
+Gives you a better understanding of the default settings and shows you how to customize them to your needs.
<li><a href="tutorial/multiple.html">Multiple Resolvers</a></li>
-teach you how to configure Ivy to find its dependencies in multiple places.
+Teaches you how to configure Ivy to find its dependencies in multiple places.
<li><a href="tutorial/dual.html">Dual Resolver</a></li>
-help you configure ivy to find ivy files in one place and artifacts in another.
-<li>[[tutorial/dependence]]Project Dependencies</a></li>
-a very first step toward using Ivy in a multi project environment.
+Helps you configure Ivy to find ivy files in one place and artifacts in another.
+<li>[[tutorial/dependence]]</a></li>
+A starting point for using Ivy in a multi-project environment.
<li>[[tutorial/multiproject]]</li>
-a more complex example demonstrating the use of Ant+Ivy in a multi project environment.
-<li>[[tutorial/conf]]</li>
-show how to use configurations in ivy file to define set of artifacts.
+A more complex example demonstrating the use of Ant+Ivy in a multi-project environment.
+<li>[[tutorial/conf]]</li> Shows you how to use configurations in an ivy file to define sets of artifacts.
<li>[[tutorial/build-repository]]</li>
-show how to build your own enterprise repository.
+Shows you how to build your own enterprise repository.
</ul>
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository.html Tue Aug 31 08:37:50 2010
@@ -25,17 +25,16 @@
</head>
<body>
<textarea id="xooki-source">
-The [[ant:install]] task let you copy a module or a set of modules from one repository to another one. This is very useful to build and maintain a enterprise or a team repository. If you don't want to give access to the public maven 2 repository to the developers in your team (to keep control over which modules are in use in your company or your team for instance), it can sometimes become tiresome to answer the developers request to add new modules or new versions by hand.
+The [[ant:install]] Ant task lets you copy a module or a set of modules from one repository to another. This is very useful to build and maintain an enterprise or team repository. If you don't want to give access to the public maven 2 repository to the developers on your team (to keep control over which modules are in use in your company or your team for instance), it can sometimes become tiresome to answer the developers request to add new modules or new versions by hand.
Fortunately the [[ant:install]] task is here to help: you can use specific settings for your repository maintenance build which will be used to maintain your target enterprise repository. These settings will point to another repository (for instance the maven 2 public repository) so that you will just have to ask Ivy to install the modules you want with a simple command line.
-To demonstrate this we will first use some basic ivy settings files to show how it works, and then we will use the advanced [[settings/namespaces]] feature to demonstrate how to deal with naming mismatch between the source and target repository.
+To demonstrate this, we will first use a basic ivy settings file to show how it works, and then we will use the advanced [[settings/namespaces]] features to demonstrate how to deal with naming mismatches between the source and target repository.
<h1>The project used</h1>
-The project that we will use is pretty simple.
-It is composed of an ant build file, and some ivy settings files.
+The project that we will use is pretty simple. It is composed of an Ant build file, and two ivy settings files.
-Here are the accessible target that we will use :
+Here are the public targets that we will use:
<div class="shell"><pre>
Z:\ivy-repository>ant -p
Buildfile: build.xml
@@ -51,7 +50,7 @@ Main targets:
Default target: basic
</pre></div>
<br/><br/>
-The project is accessible in the [[svn:src/example/build-a-ivy-repository src/example/build-a-ivy-repository]]
+This project is accessible in the [[svn:src/example/build-a-ivy-repository src/example/build-a-ivy-repository]]
Next steps:
[[tutorial/build-repository/basic]]
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/advanced.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/advanced.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/advanced.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/advanced.html Tue Aug 31 08:37:50 2010
@@ -25,20 +25,19 @@
</head>
<body>
<textarea id="xooki-source">
-Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, when the source and destination repositories don't follow the same naming conventions for instance.
+Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, like when the source and destination repositories don't follow the same naming conventions.
<h1>On the road to a professional repository</h1>
-We will study in this section how to build a <strong>professionnal</strong> repository. What is a <strong>professionnal</strong> repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer corrects, usuables, configurables and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository.
-We have seen in the previous example, that we could use some public repositories to begin to build our own repository.
-Nevertheless, the result is not always the expected one, especially concerning the naming rules used.
+In this section, you will learn how to build a <strong>professional</strong> repository. What is a <strong>professional</strong> repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer correct, useable, configurations and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository.
+We have seen in the previous example, that we could use some public repositories to begin to build our own repository. Nevertheless, the result is not always the expected one, especially concerning the naming rules used.
-This problem is pretty usual when you have an existing repository, and want to benefit from a large public repositories which do not follow the same naming conventions. Or simply because you find the public repository you use as a basis is not consistent enough - why all apache commons module aren't don't use the org.apache.commons organization? For historical reasons. But if you setup your own repository you may not want to suffer from history.
+This problem is pretty normal when you have an existing repository, and want to benefit from large public repositories which do not follow the same naming conventions. It also shows up because many public repositories do not use a consistent naming scheme. For example, why don't all the apache commons modules use the org.apache.commons organization? Well.. for historical reasons. But if you setup your own repository, you may not want to suffer from the mistakes of history.
-Fortunately Ivy has a very powerful answer to this kind of problem: [[settings/namespaces namespaces]].
+Fortunately, Ivy has a very powerful answer to this problem: [[settings/namespaces namespaces]].
<h1>Using namespaces</h1>
-If you look at the repository built with the [[tutorial/build-repository/basic previous tutorial]], you will see exactly what we were talking about: all apache commons module use their own name as organization.
+If you look at the repository built with the [[tutorial/build-repository/basic previous tutorial]], you will see exactly what we were talking about: all apache commons modules use their own name as their organization.
So let's see what Ivy can do using namespaces (we will dig into details later):
<div class="shell"><pre>
@@ -49,7 +48,7 @@ Now if we look at our repository, it see
<div class="shell"><pre>
[<tutorial/log/myrepository-content-namespace.txt>]
</pre></div>
-We can even have a look at the commons-lang ivy file in our repo:
+We can even have a look at the commons-lang ivy file in our repository:
<div><code type="xml">
<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="1.0">
@@ -63,21 +62,21 @@ We can even have a look at the commons-l
...
</code></div>
-Allright, we see that the organization is now 'apache'. But where did Ivy picked this up?
+Alright, we see that the organisation is now 'apache'. But where did Ivy pick this up?
<h2>How does this work ?</h2>
-Actually Ivy uses the same repository as before as source repository, with only one difference: the namespace parameter:
+Actually, Ivy uses the same repository as before for the source repository, with only one difference: the namespace parameter:
<code type="xml">
-<ibiblio name="libraries"
+<ibiblio name="libraries"
root="${ibiblio-maven2-root}"
m2compatible="true"
namespace="maven2"
/>
</code>
-A namespace is defined by a set of rules. These rules are based on regular expressions and tell Ivy how to convert data from the repository namespace from and to what is called the system namespace, i.e. the namespace in which Ivy runs most of the time (Ivy cache is always using the system namespace for instance).
+A namespace is defined by a set of rules. These rules are based on regular expressions and tell Ivy how to convert data from the repository namespace to what is called the system namespace, i.e. the namespace in which Ivy runs most of the time (Note: the Ivy cache always uses the system namespace).
-For the namespace we call maven2, we have declared some rules, here is one:
-<h3>rule handling imported apache maven1 projects</h3>
+For the namespace we call <i>maven2</i>, we have declared several rules. Below is one of the rules:
+<h3>rule handling the imported apache maven1 projects</h3>
<code type="xml"><rule> <!-- imported apache maven1 projects -->
<fromsystem>
<src org="apache" module=".+"/>
@@ -94,7 +93,7 @@ For the namespace we call maven2, we hav
</tosystem>
</rule></code>
<div class="postit"><u>Note about regular expressions usage :</u>
-In order to distinguish matching regular expressions found in organization, module and revision the notation used prefixes the matching regular expression with the letters 'o', 'm' and 'r'.
+In order to distinguish matching regular expressions found in organization, module, and revision, the notation Ivy uses prefixes the matching regular expression with the letters 'o', 'm' and 'r'.
$o0 : the whole matching value in the organization attribute
$o1 : the first matching expression group that was marked in the organization attribute
...
@@ -104,14 +103,16 @@ and for revisions : $r0, $r1, ...
To understand namespaces,
<ul>
<li><b>fromsystem :</b> we define here that the projects defined in the system namespace under the organization called "apache" are transformed into the destination namespace into projects whose organization is named with the module name, whatever the revision is. For example, the project apache#commons-lang;1.0 in the system namespace will be translated into commons-lang#commons-lang;1.0 in the maven2 resolver namespace.</li>
-<li><b>tosystem :</b> we define here the reverse mapping, ie how to translate <em>apache</em> projects from maven 2 repo into apache projects in the system namespace. The rule used here tells that all projects matching commons-.+ (see it as java regular expression) for their organization name and module name are transformed into projects whose organisation is apache with the module name as it was found. The same kind of rule is applied for others apache projects like ant, etc.</li>
+<li><b>tosystem :</b> we define here the reverse mapping, i.e. how to translate <em>apache</em> projects from maven 2 repo into apache projects in the system namespace. The rule used here tells Ivy that all projects matching <tt>commons-.+</tt> (see it as java regular expression) for their organization name and module name are transformed into projects whose organisation is <tt>apache</tt> with the module name as it was found. The same kind of rule is defined for others apache projects like ant, etc.</li>
</ul>
-Ok, you should now get the idea behind namespace, you can now check the whole namespace settings provided in the example, and test the installation of a module and its dependencies using namespaces.
+OK, you should now get the idea behind namespaces, so go ahead and look at the <tt>ivysettings-advanced.xml</tt> file in this example. You can test the installation of a module and its dependencies using namespaces.
-Run <code>ant maven2-namespace-deps</code> and you will see the resulting repository is cleaner than the first one we built.
+Run
+<code>ant maven2-namespace-deps</code>
+and you will see the resulting repository is cleaner than the first one we built.
-From our experience investing in creating a namespace is worth the time it costs if you often need to add new modules or revisions of third party libraries in your own repository, where naming rules are already existing or rather strict. </textarea>
+From our experience, investing in creating a namespace is worth the time it costs if you often need to add new modules or revisions of third party libraries in your own repository, where naming rules already exist or are rather strict. </textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/basic.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/basic.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/basic.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/build-repository/basic.html Tue Aug 31 08:37:50 2010
@@ -25,10 +25,10 @@
</head>
<body>
<textarea id="xooki-source">
-In this first step we use the [[ant:install]] task to install modules from the maven 2 repository to a file system based repository. We first install a module with no dependency, then a module with its dependencies.
+In this first step, we use the [[ant:install]] Ant task to install modules from the maven 2 repository to a file system based repository. We first install a module by itself, excluding dependencies, then again with its dependencies.
<h1>Basic: ivysettings.xml file used</h1>
-The ivy settings file that we will use is very simple here. It defines two resolvers, libraries and my-repository. The first one is used as the source, the second one as the destination. In a typical setup the second one would be configured using [[settings/include included]] settings, used by the development team.
+The ivy settings file that we will use is very simple here. It defines two resolvers, <i>libraries</i> and <i>my-repository</i>. The first one is used as the source, the second one as the destination. In a typical setup, the second one would be configured using an [[settings/include include]] that included an existing settings file used by the development team.
<code type="xml">
<ivysettings>
@@ -55,24 +55,24 @@ Let's have a look at the <em>maven2</em>
from="${from.resolver}" to="${to.resolver}" />
</target>
</code>
-Pretty simple, we call the [[ant:install] task with the settings we have loaded using [[ant:settings ivy:settings]] as usual, we provide fromResolver (source) and toResolver (destination) using properties to ease the maintenance of the script, but it's basically the name of our resolvers: 'libraries' for the source and 'my-repository' for the destination.
+Pretty simple, we call the [[ant:install] task with the settings we have loaded using [[ant:settings ivy:settings]] as usual. We then set the source and destination repositories using the <i>from</i> and <i>to</i> attributes. We used Ant properties for these values here, which helps ease the maintenance of the script, but it's basically the name of our resolvers: 'libraries' for the source and 'my-repository' for the destination.
-Here is the ant call output :
+Here is the Ant call output :
<div class="shell"><pre>
[<tutorial/log/install.txt>]
</pre></div>
-The trace tells us that the module definition was found using the "libraries" resolver and that the corresponding artifact was downloaded from maven 2 repository. Then both were published to the filesystem repository (my-repository).
+The trace tells us that the module definition was found using the "libraries" resolver and that the corresponding artifact was downloaded from the maven 2 repository. Then both were published to the filesystem repository (my-repository).
Let's have a look at our repository :
<div class="shell"><pre>
[<tutorial/log/myrepository-content.txt>]
</div>
-We can see that we now have the commons-lang module version 1.0 in our repository, with a generated ivy.xml file, its jar, and all the md5 and sha1 checksums for future consistency checks when developers will use this repository to resolve modules.
+We can see that we now have the commons-lang module version 1.0 in our repository, with a generated ivy.xml file, its jar, and all the md5 and sha1 checksums for future consistency checks when developers use this repository to resolve modules.
<h1>install a module with dependencies</h1>
Now let's say that we want to be sure all the dependencies of the module we install are available in our repository after the installation. We could either install without dependencies on a staging repository and check the missing dependencies (more control), or use transitive dependency management and ask Ivy to install everything for us (much simpler).
-The target called is very similar to the one described above, except that we explicitly ask for transitive installation.
+The <tt>maven2-deps</tt> target is very similar to the one described above, except that we explicitly ask for transitive installation.
<code type="xml">
<target name="maven2-deps" depends="init-ivy"
description="--> install module from maven 2 repository with dependencies">
@@ -88,13 +88,13 @@ If you call this target, you will see th
</pre>
</div>
-As you can see the installation has failed, if you look at the log you will see that there are missing artifacts on the source repository. This means that you will need to download those artifacts manually, and copy them to your destination repository to complete the installation. Fortunately Ivy use a best effort algorithm during install, so that you have everything installed but the missing artifacts.
+As you can see the installation has failed, if you look at the log you will see that there are missing artifacts on the source repository. This means that you will need to download those artifacts manually, and copy them to your destination repository to complete the installation. Fortunately Ivy uses a best effort algorithm during install, so that everything gets installed except the missing artifacts. (Note: these missing artifacts are not in the public maven repository due to licensing issues)
-You may also have notice that Ivy has installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we use the "no conflict" [[settings/conflict-managers conflict manager]] in the ivysettings file.
+You may also have noticed that Ivy installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we used the "no conflict" [[settings/conflict-managers conflict manager]] in the ivysettings file.
-We do not want to evict any modules because we are building our own repository. Indeed if we get both commons-logging 1.0.2 and 1.0.4 it's because some modules among the transitive dependencies of hibernate depend on 1.0.2 and other on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 would be inconsistent in your own repository (depending on a version you don't have installed). Thus developers using this module directly would run into a problem.
+We do not want to evict any modules because we are building our own repository. Indeed if we get both commons-logging 1.0.2 and 1.0.4 it's because some modules among the transitive dependencies of hibernate depend on 1.0.2 and others on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 would be inconsistent in your own repository (depending on a version you don't have installed). Thus developers using this module directly would run into a problem.
-If you now have a closer look at your repository, you will probably notice that it isn't an exact replication of the original one. Let's have a look at one module content:
+If you now have a closer look at your repository, you will probably notice that it isn't an exact replication of the original one. Let's have a look at the directory of one module:
<div class="shell"><pre>
[<tutorial/log/myrepository-content-deps.txt>]
</pre>
@@ -102,7 +102,7 @@ If you now have a closer look at your re
As you can see there is no pom here (pom is the module metadata format used by maven 2, available on the maven 2 repository). Instead you can see there's an ivy file, which is actually the original hibernate pom converted into an ivy file. So now you have a true Ivy repository with ivy files, where you can use the full power of Ivy if you want to adjust the module metadata (module configurations, fine grain exclusions and transitivity control, per module conflict manager, ...).
-Ok, enough for this simple repository installation, the [[tutorial/build-repository/advanced next tutorial]] will now show how you can deal with more complex cases where your source and destination repositories do not follow the same naming conventions.</textarea>
+OK, enough for this simple repository installation, the [[tutorial/build-repository/advanced next tutorial]] will show how you can deal with more complex cases where your source and destination repositories do not follow the same naming conventions.</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/conf.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/conf.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/conf.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/conf.html Tue Aug 31 08:37:50 2010
@@ -25,27 +25,26 @@
</head>
<body>
<textarea id="xooki-source">
-This tutorial introduces the use of module configurations in ivy files. Ivy module configurations is indeed a very important concept. Someone even told me one day that using Ivy without using configurations is like eating a good cheese without touching the glass of Chateau Margaux 1976 you have just aside :-)
+This tutorial introduces the use of module configurations in ivy files. Ivy module configurations are indeed a very important concept. Someone even told me one day that using Ivy without using configurations is like eating a good cheese without touching the glass of Chateau Margaux 1976 you have just poured :-)
-More seriously, configurations in ivy can be better understood as views on your module, and you will see how they can be used efficiently here.
+More seriously, configurations in Ivy can be better understood as views on your module, and you will see how they can be used effectively here.
Reference documentation on configurations can be found <a href="../terminology.html">here</a> and <a href="../ivyfile/configurations.html">here</a>.
<h1>Introduction</h1>
-Source code available in src/example/configurations/multi-projects.
+Source code is available in <tt>src/example/configurations/multi-projects</tt>.
We have two projects :
- filter-framework is a library that defines an api to filter String arrays and two implementations of this api.
- myapp is a very small app that uses filter-framework.
-The library produces 3 artifacts:
+The filter-framework library project produces 3 artifacts:
- the api jar,
- - an implementation jar with no external dependency,
- - an other implementation that needs commons-collections to perform.
+ - an implementation jar with no external dependencies,
+ - a second implementation jar that needs commons-collections to perform.
-The application only need api to compile and can use any of the two implementation at runtime.
+The application only needs the api jar to compile and can use either of the two implementations at runtime.
<h1>The library project</h1>
-The first project we defined in this tutorial is the filter-framework.
-In order to have a fine grained artifacts publication definition, we defined configurations to map usage other can make of our library.
+The first project we'll look at in this tutorial is filter-framework. In order to have a fine-grained artifacts publication definition, we defined several configurations, each which maps to a set of artifacts that other projects can make use of.
<h2>The ivy.xml file</h2>
<div class="ivy-file">
@@ -71,26 +70,22 @@ In order to have a fine grained artifact
</code>
</div>
<h2>Explanation</h2>
-As you can see we defined 3 public configurations and a private one (defined junit dependency for testing).
-The 2 implementations conf <b>homemade-impl</b>, <b>cc-impl</b> extends <b>api</b> configuration so artifacts defined in api will also be required in its extending conf.
-In the publications tag we defined the artifacts we produce (here it's jars) and we affect them a configuration.
-Later when others will use our library they will have a very flexible way to define what they need.
+As you can see, we defined 4 configurations, with 3 being public and 1 private. (the junit dependency for testing).
+The 2 implementation configurations, <b>homemade-impl</b> and <b>cc-impl</b> extend the <b>api</b> configuration so that all artifacts defined in <b>api</b> will also be part of the extending configuration.
+
+In the publications tag, we defined the artifacts we produce (jars in this case) and we assign them to a configuration. When others use our library they will have a flexible way to ask for what they need.
<h2>See it in action</h2>
-The library project is build using ant. Open a shell in the root directory of the project and type <b>ant</b>.
+The filter-framework project is built using Ant. Open a shell in the root directory of the project and type <tt>ant</tt>.
<div class="shell"><pre>
[<tutorial/log/configurations-lib.txt>]
</pre></div>
-The ant's default target is publish.
-This target uses ivy to publish our library binaries in a local repository.
-As we do not specify any repository path the default one is used. ({home.dir}/.ivy2/local/org.apache/filter-framework/)
-Now we are ready to use our library.
+The Ant default target is publish. This target uses Ivy to publish our library binaries to a local repository. Since we do not specify any repository path, the default one is used. (<tt>${home.dir}/.ivy2/local/org.apache/filter-framework/</tt>) At this point, we are ready to use our library.
<h1>The application project</h1>
-Now that we have shipped our fantastic library, we want to use it!
-The tutorial comes with a sample application called myapp.
-<h2>The ivy.xml file</h2>
+Now that we have shipped (published) our fantastic filter library, we want to use it! The tutorial comes with a sample application called myapp.
+<h2>The <tt>ivy.xml</tt> file</h2>
<div class="ivy-file">
<code type="xml">
@@ -110,21 +105,17 @@ The tutorial comes with a sample applica
</code>
</div>
<h2>Explanation</h2>
-We create 3 configurations that define the way we want to use the application.
-The build configuration defines the compile-time dependencies, and thus only needs the api conf from filter-framework.
-The other configurations define runtime dependencies. One will only use "home-made" jars, and the other will use external jars.
-
-We also defined a dependency on the previous library.
-In the dependency we use configuration mapping to match ours and library configurations.
-You can found more information on configuration mapping <a href="../ivyfile/configurations.html">here</a>
+We create 3 configurations that define the different ways we want to use the application. The <b>build</b> configuration defines the compile-time dependencies, and thus only needs the api conf from the filter-framework project. The other two configurations define runtime dependencies. One will only use our "home-made" jar, and the other will use an external jar.
+
+We also defined a dependency on our previously built library. In this dependency, we use configuration mappings to match ours with the dependency's configurations. You can find more information about configuration mapping <a href="../ivyfile/configurations.html">here</a>
<ol>
- <li><b>build->api</b> : here we tell ivy that our <b>build</b> configuration depends on the <b>api</b> configuration of the dependcy</li>
- <li><b>noexternaljar->homemade-impl</b> : here we tell ivy that our <b>noexternaljar</b> configuration depends on the <b>homemade-impl</b> configuration of the dependcy.</li>
- <li><b>withexternaljar->cc-impl</b> : here we tell ivy that our <b>withexternaljar</b> configuration depends on the <b>cc-impl</b> configuration of the dependcy</li>
+ <li><b>build->api</b> : here we tell Ivy that our <b>build</b> configuration depends on the <b>api</b> configuration of the dependency</li>
+ <li><b>noexternaljar->homemade-impl</b> : here we tell Ivy that our <b>noexternaljar</b> configuration depends on the <b>homemade-impl</b> configuration of the dependency.</li>
+ <li><b>withexternaljar->cc-impl</b> : here we tell Ivy that our <b>withexternaljar</b> configuration depends on the <b>cc-impl</b> configuration of the dependency</li>
</ol>
-Note that we never declare any of the dependency artifacts we need in each configuration: it's the dependency module file which declares the published artifacts and which should be used in each configuration.
+Note that we never declare any of the dependency's artifacts we need in each configuration: it's the dependency module's ivy file which declares the published artifacts and which should be used in each configuration.
-In the ant buld.xml file we defined a resolve target as follow:
+In the Ant <tt>build.xml</tt> file, we defined a 'resolve' target as follow:
<code type="xml">
<target name="resolve" description="--> retreive dependencies with ivy">
@@ -132,7 +123,7 @@ In the ant buld.xml file we defined a re
</target>
</code>
-When we call this target, Ivy will do a resolve using our ivy.xml file in the root folder and then retrieve all the artifacts. The artifacts retrieved are kept in separate folders according to the configurations they belong to. Here is how your lib directory should look like after a call to this target:
+When we call this target, Ivy will do a resolve using our <tt>ivy.xml</tt> file in the root folder and then retrieve all the artifacts. The artifacts retrieved are kept in separate folders according to the configurations they belong to. Here is how your lib directory should look after a call to this target:
<div class="shell"><pre>
Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib
@@ -158,27 +149,24 @@ When we call this target, Ivy will do a
01/24/2006 10:53 AM 1,626 filter-ccimpl.jar
3 fichier(s) 562,166 octets
</pre></div>
-As you can see for each configuration we have now a set of jars.
+As you can see, for each configuration we have now a set of jars.
Let's try to launch our app.
<h2>See it in action</h2>
-Use ant to run the application.
-Default ant target is run-cc and will launch application using the Apache commons-collections implementation.
+Use Ant to run the application. The default Ant target is <i>run-cc</i> and will launch the application using the Apache commons-collections implementation.
<div class="shell"><pre>
[<tutorial/log/configurations-runcc.txt>]
</pre></div>
-Launching application with only home made jars is straightforward.
-type ant run-hm
+Launching the application using the homemade implementation is also straightforward.
+type <tt>ant run-hm</tt>
<div class="shell"><pre>
[<tutorial/log/configurations-runhm.txt>]</pre></div>
-Nice we got the same result but we can see that implementation classes are different.
+Nice! We got the same result, but we can see that the implementation classes are different.
<h1>Conclusion</h1>
-<b>You should use configurations as often as possible</b>
-Configurations are very important concept in ivy. They allow you to group artifacts by meaning.
-When you write ivy file for projects that are supposed to be reused, use configurations to allow people to get only they what they need without having to specify it by hand using artifact tag in dependency section.
+<b>You should use configurations as often as possible.</b> Configurations are a very important concept in Ivy. They allow you to group artifacts and give the group a meaning. When you write ivy files for projects that are intended for use by others, use configurations to allow people to get only what they need, without having to specify them one by one in their own dependency list.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
Modified: ant/ivy/core/branches/2.2.x/doc/tutorial/defaultconf.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/branches/2.2.x/doc/tutorial/defaultconf.html?rev=991118&r1=991117&r2=991118&view=diff
==============================================================================
--- ant/ivy/core/branches/2.2.x/doc/tutorial/defaultconf.html (original)
+++ ant/ivy/core/branches/2.2.x/doc/tutorial/defaultconf.html Tue Aug 31 08:37:50 2010
@@ -25,47 +25,47 @@
</head>
<body>
<textarea id="xooki-source">
-Ivy comes bundled with some default settings which makes it pretty simple to use in common environment. This tutorial, which is close to a reference documentation, explains what are those default settings and how they can be adjusted to your needs.
+Ivy comes bundled with some default settings which makes it pretty simple to use in a typical environment. This tutorial, which is close to a reference document, explains what those default settings are and how they can be adjusted to your needs.
-To fully understand the concept of settings and what you can do with them, we suggest reading other tutorial related to settings (like [[tutorial/multiple]] and [[tutorial/dual]]) or the [[settings]] reference documentation.
+To fully understand the concept of settings and what you can do with them, we suggest reading other tutorials related to settings (like [[tutorial/multiple]] and [[tutorial/dual]]) or the [[settings]] reference documentation.
<h1>Concept</h1>
-This default settings mainly consist of 3 kind of repositories:
+The default settings include 3 types of repositories:
<ul>
<li>local</li> a repository which is private to the user.
-<li>shared</li> a repository which is shared between all the member of a team
+<li>shared</li> a repository which is shared between all the members of a team
<li>public</li> a public repository on which most modules, and especially third party modules, can be found
</ul>
-Note that if you work alone, the distinction between local and shared repository is not very important, but there are some things to know to distinguish them.
+Note that if you work alone, the distinction between a local and shared repository is not very important, but there are some things you should know to distinguish them.
-Now let's describe each of these repositories concept in more details. We will describe how they are setup physically later.
+Now let's describe each of these repository concepts in more detail. We will describe how they are set up physically later.
<h2>Local</h2>
-The local repository is particularly useful when you want to do something without being disturbed by anything else happening in the environment. This means that whenever ivy is able to locate a module in this repository it will be used, no matter of what is available in others.
+The local repository is particularly useful when you want to do something without being disturbed by anything else happening in the environment. This means that whenever Ivy is able to locate a module in this repository it will be used, no matter what is available in others.
-For instance, if you have a module declaring a dependency on the module foo in revision latest.integration, then if a revision of foo is found in the local repository, it will be used, <em>even if a more recent revision is available in other repositories</em>.
+For instance, if you have a module declaring a dependency on the module <i>foo</i> with a revision of <i>latest.integration</i>, then if a revision of <i>foo</i> is found in the local repository, it will be used, <em>even if a more recent revision is available in other repositories</em>.
-This may be disturbing for some of you, but imagine you have to implement a new feature on a project, and in order to achieve that you need to modify two modules: you add a new method in module foo and exploit this new method in module bar. Then if you publish the module foo to your local repository, you will be sure to get it in your bar module, even if someone else publish a new revision of foo in the shared repository (this revision not having the new method you are currently adding).
+This may be disturbing for some of you, but imagine you have to implement a new feature on a project, and in order to achieve that you need to modify two modules: you add a new method in module <i>foo</i> and exploit this new method in module <i>bar</i>. Then if you publish the module <i>foo</i> to your local repository, you will be sure to get it in your <i>bar</i> module, even if someone else publishes a new revision of <i>foo</i> in the shared repository (this revision not having the new method you are currently adding).
-But be careful, when you have finished your development and publish it on the shared you will have to clean your local repository to benefit from new versions published in the shared repository.
+But be careful, when you have finished your development and publish it on the shared repository, you will have to clean your local repository to benefit from new versions published in the shared repository.
Note also that modules found in the local repository must be complete, i.e. they must provide both a module descriptor and the published artifacts.
<h2>Shared</h2>
-As its name suggest, the shared repository is aimed to be shared among a whole development team. It is a place where you can publish your team private modules for instance, and it's also a place where you can put modules not available in the public repository (sun jars, for instance), or simply not accurate (bad or incomplete module descriptors for instance).
+As its name suggest, the shared repository is aimed to be shared among a whole development team. It is a place where you can publish your team's private modules, and it's also a place where you can put modules not available in the public repository (sun jars, for instance). You can also put modules here that are simply inaccurate in a public repository (bad or incomplete module descriptors for instance).
-Note that modules can be split across the shared repository and the public one: you can have the module descriptor in the shared repository and the artifacts in the public one, for instance.
+Note that modules can be split across the shared repository and the public one: For example, you can have the module descriptor in the shared repository and the artifacts in the public one.
<h2>Public</h2>
The public repository is the place where most modules can be found, but which sometimes lack the information you need. It's usually a repository available through an internet connection only, even if this is not mandatory.
<h1>Setting up the repositories</h1>
Now that we have seen the objective of each of the three repositories, let's see how they are setup and how to configure them to fit your needs.
-First, several repositories uses the same root in your filesystem. Referenced as ${ivy.default.ivy.user.dir}, this is by default the directory .ivy2 in your user home.
+First, several repositories use the same root in your filesystem. Referenced as <tt>${ivy.default.ivy.user.dir}</tt>, this is by default the directory <tt>.ivy2</tt> in your user home.
-Note that several things can be done by setting ivy variable. To set them without defining your own ivysettings.xml file, you can:<ul>
-<li>set an ant property before any call to ivy in your build file if you use ivy from ant</li>
-<li>set an environment variable if you use ivy from the command line</li>
+Note that several things can be done by setting Ivy variables. To set them without defining your own <tt>ivysettings.xml</tt> file, you can:<ul>
+<li>set an Ant property before any call to Ivy in your build file if you use Ivy from Ant</li>
+<li>set an environment variable if you use Ivy from the command line</li>
</ul>
-For instance:
+For example:
<code type="xml">
<target name="resolve">
<property name="ivy.default.ivy.user.dir" value="/path/to/ivy/user/dir"/>
@@ -73,9 +73,9 @@ For instance:
</target>
</code>
-Now we will show how to override default values for the different kind of repositories, note that you can find what are these default values below in the detail of the default settings.
+Next we will show you how to override default values for the different kinds of repositories. Note that you can find what the default values are below in the details of the default settings.
<h2>Local</h2>
-By default, the local repository lies in ${ivy.default.ivy.user.dir}/local. This is usually a good place, but you may want to modify it however. No problem, you just have to set the following ivy variable to the directory you want to use: <code>ivy.local.default.root</code>. For instance:
+By default, the local repository lies in <tt>${ivy.default.ivy.user.dir}/local</tt>. This is usually a good place, but you may want to modify it. No problem, you just have to set the following Ivy variable to the directory you want to use: <code>ivy.local.default.root</code>. For instance:
<code>ivy.local.default.root=/opt/ivy/repository/local</code>.
If you already have something you would like to use as your local repository, you may also want to modify the layout of this repository. Once again, two variables are available for that:
@@ -88,7 +88,7 @@ ivy.local.default.ivy.pattern=[module]/[
ivy.local.default.artifact.pattern=[module]/[revision]/[artifact].[ext]
</code>
<h2>Shared</h2>
-By default, the shared repository lies in ${ivy.default.ivy.user.dir}/shared. This is fine if you work alone, but the shared repository is supposed to be, mmm, shared! So changing this directory is often required, and it is usually modified to point to a network shared directory. You can use <code>ivy.shared.default.root</code> variable to specify in a new directory. Moreover, you can also configure the layout with variables similar to the one for the local repository:
+By default, the shared repository lies in <tt>${ivy.default.ivy.user.dir}/shared</tt>. This is fine if you work alone, but the shared repository is supposed to be, mmm, shared! So changing this directory is often required, and it is usually modified to point to a network shared directory. You can use the <code>ivy.shared.default.root</code> variable to specify a different directory. Moreover, you can also configure the layout with variables similar to the ones used for the local repository:
<code>ivy.shared.default.ivy.pattern</code> gives the pattern to find ivy files
<code>ivy.shared.default.artifact.pattern</code> gives the pattern to find artifacts
For example:
@@ -105,17 +105,17 @@ This repository has the advantage of pro
Despite its ease of use, we suggest reading the [[bestpractices]] to have a good understanding of the pros and cons of using a public unmanaged repository before depending on such a repository for your enterprise build system.
-<em>In 1.4 version Ivy was using ivyrep has default resolver, if you want to restore this, set
+<em>In 1.4 version Ivy was using ivyrep as the default resolver, if you want to restore this, set
ivy.14.compatible=true as an ant property</em>
<h1>Going further</h1>
-OK, so we have seen how to easily change the settings of the three main repositories. But what if my shared repository is on a web server? What if you don't want to use maven 2 repository as public repository? What if ...
+OK, so we have seen how to easily change the settings of the three main repositories. But what if my shared repository is on a web server? What if you don't want to use maven 2 repository as the public repository? What if ...
-No problem, Ivy is very flexible and can be configured with very specific settings to match your needs and environment. But before considering writing your own settings from scratch, we suggest reading the following where you will learn how to leverage a part of the default settings and adjust the rest.
+No problem, Ivy is very flexible and can be configured with specific settings to match your needs and environment. But before considering writing your own settings from scratch, we suggest reading the following where you will learn how to leverage a part of the default settings and adjust the rest.
-But before explaining how, you will need to have a quick overview of how ivy is configured by default.
+But before explaining how, you will need to have a quick overview of how Ivy is configured by default.
-By default, ivy is configured using an ivysettings.xml which is packaged in the ivy jar. Here is this settings file:
+By default, Ivy is configured using an <tt>ivysettings.xml</tt> which is packaged in the Ivy jar. Here is this settings file:
<code type="xml">
<ivysettings>
<settings defaultResolver="default"/>
@@ -126,7 +126,7 @@ By default, ivy is configured using an i
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
</code>
-OK, so not much info here, except a lot of inclusions. These inclusions have been done on purpose so that you can easily change only one part of the ivysettings and benefit of the rest easily. For example, if you want to define your own public resolver, you will just have to configure ivy with an ivysettings like that:
+OK, so not much info here, except a lot of inclusions. These inclusions have been done on purpose so that you can easily change only one part of the ivysettings and easily benefit from the rest. For example, if you want to define your own public resolver, you will just have to configure Ivy with an ivysettings like the following:
<code type="xml">
<ivysettings>
<settings defaultResolver="default"/>
@@ -137,7 +137,7 @@ OK, so not much info here, except a lot
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
</code>
-Note that only the ivysettings-public inclusion has changed to include a home made public resolver. Note also that this can be used like that thanks to the fact that ${ivy.default.settings.dir} is a variable which is always set to the place where ivy default settings files are (i.e. packaged in the jar).
+Note that only the <tt>ivysettings-public.xml</tt> inclusion has changed to include a homemade public resolver. Note also that this can be used like that thanks to the fact that <tt>${ivy.default.settings.dir}</tt> is a variable which is always set to the place where Ivy's default settings files are (i.e. packaged in the jar).
To finish this example, you have to write your own ivysettings file (that you will make available at http://myserver/ivy/myivysettings-public.xml in this example) for defining your own public resolver. For instance:
<code type="xml">
<ivysettings>
@@ -209,7 +209,7 @@ Now the last thing you will need in orde
</ivysettings>
</code>
-Here you are, you have enough clues to configure that the way you want... check the [[settings settings documentation]] to see if what you want to do is possible, and go ahead!
+There you go, you should have enough clues to configure Ivy the way you want. Check the [[settings settings documentation]] to see if what you want to do is possible, and go ahead!
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>