Author: xavier
Date: Sun Feb 25 02:10:21 2007
New Revision: 511475
URL: http://svn.apache.org/viewvc?view=rev&rev=511475
Log:
FIX: dependencies graph missing in multiproject tutorial (IVY-410)
Modified:
incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html
Modified: incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html
URL:
http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html?view=diff&rev=511475&r1=511474&r2=511475
==============================================================================
--- incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html (original)
+++ incubator/ivy/core/trunk/doc/doc/tutorial/multiproject.html Sun Feb 25
02:10:21 2007
@@ -5,163 +5,163 @@
<script type="text/javascript" src="../../xooki/xooki.js"></script>
</head>
<body>
- <textarea id="xooki-source">
-<strong>Warning: tutorial in progress !</strong>
-
-In the previous tutorial you have seen 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 (warning: the sources attached
with ivy 1.3 contain an error in the common.xml file. Please use either latest
build to find proper example sources or replace the common.xml file with <a
href="./misc/ivy/samples/multi-project/common.xml">this one</a>).
-
-<h1>Context</h1>
-Here is a 10000ft overview of the projects involved in this tutorial:
-<ul>
-<li>version</li> helps to identify module by a version
-<li>list</li> gives a list of files in a directory (recursively)
-<li>size</li> gives the total size of all files in a directory, or of a
collection of files
-<li>find</li> find files in a given dir or among a list of files which match a
given name
-<li>sizewhere</li> gives the total size of files matching a name in a directory
-<li>console</li> give access to all other modules features through a simple
console app
-</ul>
-For sure this is not aimed to demonstrate how to develop a complex app or give
indication of advanced algorithm :-)
-
-But this gives a simple understanding of how ivy can be used to develop an
application divided in multitple modules.
-
-Now, here is how these modules relate to each other:
-<a href="/misc/ivy/samples/projects-dependencies-graph.jpg"><img
src="/misc/ivy/samples/projects-dependencies-graph-small.jpg" alt="dependencies
graph"/><br/><center><i>click to enlarge</i></center></a>
-
-Modules in yellow are the modules described in this tutorial, and modules in
blue are external dependencies (we will see how to generate this graph later in
this tutorial).
-
-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:
-<ul>
-<li><a
href="./misc/ivy/samples/multi-project/build.xml">build.xml</a></li>This 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
-<ul>
-<li><a href="./misc/ivy/samples/multi-project/common.xml">common.xml</a></li>
the common build file imported by all build.xml files for each project. This
build defines the targets which can be used in all projects.
-<li>build.properties</li>some properties common to all projects
-</ul>
-</li>
-<li>projects</li>
-contains a directory per module, with for each
-<ul>
-<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">
- <info
- organisation="jayasoft"
- module="find"
- status="integration"/>
- <configurations>
- <conf name="core"/>
- <conf name="standalone" extends="core"/>
- </configurations>
- <publications>
- <artifact name="find" type="jar" conf="core" />
- </publications>
- <dependencies>
- <dependency name="version" rev="latest.integration" conf="core->default"
/>
- <dependency name="list" rev="latest.integration" conf="core" />
- <dependency org="apache" name="commons-collections" rev="3.1"
conf="core->default" />
- <dependency org="apache" name="commons-cli" rev="1.0"
conf="standalone->default" />
- </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:
-<code type="xml">
-<project name="find" default="compile">
- <property file="build.properties"/>
-
- <import file="${common.dir}/common.xml"/>
-</project>
-</code>
-<li>build.properties</li>Module specific properties + properties to find the
common build file
-<code>
-projects.dir = ${basedir}/..
-wkspace.dir = ${projects.dir}/..
-common.dir = ${wkspace.dir}/common
-</code>
-<li>src</li> the source directory with all java sources
-</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 this 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 (with which you should begin to
be familiar).
-
-So, here are some aspects of this common build file:
-<h2>ivy configuration</h2>
-<code type="xml">
-<target name="configure">
- <!-- setup ivy default configuration with some custom info -->
- <property name="ivy.local.default.root" value="${repository.dir}/local"/>
- <property name="ivy.shared.default.root" value="${repository.dir}/shared"/>
-
- <!-- here is how we would have configured ivy if we had our own ivyconf
file
- <ivy:configure file="${common.dir}/ivyconf.xml" />
- -->
-</target>
-</code>
-
-This target configures ivy only by setting two properties: the location for
the local repository and the location for the shared repository. It's the only
configuration done here, since ivy 1.3 is configured by default to work in a
team environment (see <a href="../../tutorial/defaultconf.html">default
configuration tutorial</a> 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 configuration
tutorial to see how to use something really different).
-This target only indicates in comments how the configuration would have been
done if the default configuration wasn't ok for our purpose.
-
-<h2>resolve dependencies</h2>
-<code type="xml">
-<target name="resolve" depends="configure, clean-lib" description="-->
retrieve dependencies with ivy">
- <mkdir dir="${lib.dir}"/> <!-- not usually necessary, ivy creates the
directory IF there are dependencies -->
- <!-- this target is named resolve even if we do a retrieve:
- in fact a resolve will be called, and then the retrieve will simply
copy files in the lib directory -->
- <ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" />
-</target>
-</code>
-Here we see that we only call a retrieve task, the resolve being done
automatically with default parameters (which are ok in our case). So here
nothing special, we simply use ivy to retrieve dependencies in the lib
directory, putting artifacts without revision in their names (it's easier to
use with an ide, for instance).
-
-<h2>publish</h2>
-<code type="xml">
-<target name="publish" depends="clean-build, new-version, jar"
description="--> publish this project in the ivy repository">
- <property name="revision" value="${version}"/>
- <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
- resolver="shared"
- pubrevision="${revision}"
- status="release"
- />
- <echo message="project ${ant.project.name} released with version
${revision}" />
-</target>
-</code>
-This target let publish the module in the shared repository, with the revision
found in the version property, which is set by other targets. It can be used
when a module reaches a specific milestone, or whenever you want the teeam 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">
- <delete file="${build.dir}/ivy.xml"/> <!-- delete last produced ivy file
to be sure a new one will be generated -->
- <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
- resolver="local"
- pubrevision="${revision}"
- pubdate="${now}"
- status="integration"
- />
- <echo message="project ${ant.project.name} published locally with version
${revision}" />
-</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.
-<h2>clean-local</h2>
-<code type="xml">
-<target name="clean-local" depends="configure" 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.
-<h2>report</h2>
-<code type="xml">
-<target name="report" depends="resolve" description="--> generates a report of
dependencies">
- <ivy:report todir="${build.dir}"/>
-</target>
-</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 <a
href="http://www.jayasoft.org/ivy/doc/yed";>here</a> 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 !
+ <textarea id="xooki-source">
+<strong>Warning: tutorial in progress !</strong>
+
+In the previous tutorial you have seen 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 (warning: the sources attached
with ivy 1.3 contain an error in the common.xml file. Please use either latest
build to find proper example sources or replace the common.xml file with <a
href="../../samples/multi-project/common.xml">this one</a>).
+
+<h1>Context</h1>
+Here is a 10000ft overview of the projects involved in this tutorial:
+<ul>
+<li>version</li> helps to identify module by a version
+<li>list</li> gives a list of files in a directory (recursively)
+<li>size</li> gives the total size of all files in a directory, or of a
collection of files
+<li>find</li> find files in a given dir or among a list of files which match a
given name
+<li>sizewhere</li> gives the total size of files matching a name in a directory
+<li>console</li> give access to all other modules features through a simple
console app
+</ul>
+For sure this is not aimed to demonstrate how to develop a complex app or give
indication of advanced algorithm :-)
+
+But this gives a simple understanding of how ivy can be used to develop an
application divided in multitple modules.
+
+Now, here is how these modules relate to each other:
+<a href="../../samples/projects-dependencies-graph.jpg"><img
src="../../samples/projects-dependencies-graph-small.jpg" alt="dependencies
graph"/><br/><center><i>click to enlarge</i></center></a>
+
+Modules in yellow are the modules described in this tutorial, and modules in
blue are external dependencies (we will see how to generate this graph later in
this tutorial).
+
+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:
+<ul>
+<li><a
href="./misc/ivy/samples/multi-project/build.xml">build.xml</a></li>This 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
+<ul>
+<li><a href="./misc/ivy/samples/multi-project/common.xml">common.xml</a></li>
the common build file imported by all build.xml files for each project. This
build defines the targets which can be used in all projects.
+<li>build.properties</li>some properties common to all projects
+</ul>
+</li>
+<li>projects</li>
+contains a directory per module, with for each
+<ul>
+<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">
+ <info
+ organisation="jayasoft"
+ module="find"
+ status="integration"/>
+ <configurations>
+ <conf name="core"/>
+ <conf name="standalone" extends="core"/>
+ </configurations>
+ <publications>
+ <artifact name="find" type="jar" conf="core" />
+ </publications>
+ <dependencies>
+ <dependency name="version" rev="latest.integration" conf="core->default"
/>
+ <dependency name="list" rev="latest.integration" conf="core" />
+ <dependency org="apache" name="commons-collections" rev="3.1"
conf="core->default" />
+ <dependency org="apache" name="commons-cli" rev="1.0"
conf="standalone->default" />
+ </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:
+<code type="xml">
+<project name="find" default="compile">
+ <property file="build.properties"/>
+
+ <import file="${common.dir}/common.xml"/>
+</project>
+</code>
+<li>build.properties</li>Module specific properties + properties to find the
common build file
+<code>
+projects.dir = ${basedir}/..
+wkspace.dir = ${projects.dir}/..
+common.dir = ${wkspace.dir}/common
+</code>
+<li>src</li> the source directory with all java sources
+</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 this 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 (with which you should begin to
be familiar).
+
+So, here are some aspects of this common build file:
+<h2>ivy configuration</h2>
+<code type="xml">
+<target name="configure">
+ <!-- setup ivy default configuration with some custom info -->
+ <property name="ivy.local.default.root" value="${repository.dir}/local"/>
+ <property name="ivy.shared.default.root" value="${repository.dir}/shared"/>
+
+ <!-- here is how we would have configured ivy if we had our own ivyconf
file
+ <ivy:configure file="${common.dir}/ivyconf.xml" />
+ -->
+</target>
+</code>
+
+This target configures ivy only by setting two properties: the location for
the local repository and the location for the shared repository. It's the only
configuration done here, since ivy 1.3 is configured by default to work in a
team environment (see <a href="../../tutorial/defaultconf.html">default
configuration tutorial</a> 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 configuration
tutorial to see how to use something really different).
+This target only indicates in comments how the configuration would have been
done if the default configuration wasn't ok for our purpose.
+
+<h2>resolve dependencies</h2>
+<code type="xml">
+<target name="resolve" depends="configure, clean-lib" description="-->
retrieve dependencies with ivy">
+ <mkdir dir="${lib.dir}"/> <!-- not usually necessary, ivy creates the
directory IF there are dependencies -->
+ <!-- this target is named resolve even if we do a retrieve:
+ in fact a resolve will be called, and then the retrieve will simply
copy files in the lib directory -->
+ <ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" />
+</target>
+</code>
+Here we see that we only call a retrieve task, the resolve being done
automatically with default parameters (which are ok in our case). So here
nothing special, we simply use ivy to retrieve dependencies in the lib
directory, putting artifacts without revision in their names (it's easier to
use with an ide, for instance).
+
+<h2>publish</h2>
+<code type="xml">
+<target name="publish" depends="clean-build, new-version, jar"
description="--> publish this project in the ivy repository">
+ <property name="revision" value="${version}"/>
+ <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
+ resolver="shared"
+ pubrevision="${revision}"
+ status="release"
+ />
+ <echo message="project ${ant.project.name} released with version
${revision}" />
+</target>
+</code>
+This target let publish the module in the shared repository, with the revision
found in the version property, which is set by other targets. It can be used
when a module reaches a specific milestone, or whenever you want the teeam 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">
+ <delete file="${build.dir}/ivy.xml"/> <!-- delete last produced ivy file
to be sure a new one will be generated -->
+ <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
+ resolver="local"
+ pubrevision="${revision}"
+ pubdate="${now}"
+ status="integration"
+ />
+ <echo message="project ${ant.project.name} published locally with version
${revision}" />
+</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.
+<h2>clean-local</h2>
+<code type="xml">
+<target name="clean-local" depends="configure" 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.
+<h2>report</h2>
+<code type="xml">
+<target name="report" depends="resolve" description="--> generates a report of
dependencies">
+ <ivy:report todir="${build.dir}"/>
+</target>
+</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 <a
href="http://www.jayasoft.org/ivy/doc/yed";>here</a> 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 !
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
