Added: ant/ivy/site/target/history/2.2.0-rc1/tutorial/multiproject.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/tutorial/multiproject.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/tutorial/multiproject.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/tutorial/multiproject.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,233 @@ + + + + + + + + +Using Ivy in multiple projects environment | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Using Ivy in multiple projects environment

+
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.

Context

+Here is a 10000ft overview of the projects involved in this tutorial: +
    +
  • version
  • helps to identify module by a version +
  • list
  • gives a list of files in a directory (recursively) +
  • size
  • gives the total size of all files in a directory, or of a collection of files +
  • find
  • find files in a given dir or among a list of files which match a given name +
  • sizewhere
  • gives the total size of files matching a name in a directory +
  • console
  • give access to all other modules features through a simple console app +
+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 Ant+Ivy can be used to develop an application divided in multiple modules.

Now, here is how these modules relate to each other:
dependencies graph
click to enlarge
+ +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.

The example files

+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: +
    +
  • build.xml
  • This is a root build file which can be used to call targets on all modules, in the order of their dependencies (ensuring that a module is always built before any module depending on it, for instance) +
  • common +
      +
    • common.xml
    • 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. +
    • build.properties
    • some properties common to all projects +
    +
  • +
  • projects
  • +contains a directory per module, with for each +
      +
    • ivy.xml
    • Ivy file of the module, describing its dependencies upon other modules and / or external modules.
      Example: +
      +<ivy-module version="1.0">
      <info
      organisation="org.apache.ivy.example"
      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="commons-collections" name="commons-collections" rev="3.1 " conf="core->default" />
      <dependency org="commons-cli" name="commons-cli" rev="1.0" conf="standalone->default" />
      </dependencies>
      </ivy-module> +
      +
    • build.xml
    • The build file of the project, which consists mainly in an import of the common build file and of a module specific properties file: +
      +<project name="find" default="compile">
      <property file="build.properties"/>

      <import file="${common.dir}/common.xml"/>
      </project> +
      +
    • build.properties
    • Module specific properties + properties to find the common build file +
      +projects.dir = ${basedir}/..
      wkspace.dir = ${projects.dir}/..
      common.dir = ${wkspace.dir}/common +
      +
    • src
    • the source directory with all java sources +
    +
+ +Note that this doesn't demonstrate good practice for software development in general, in particular you won't find any unit test in these samples, even if we think unit testing is very important. But this isn't the aim of this tutorial.

Now that you are a bit more familiar with the structure, let's have a look at the most important part of this example: the common build file. Indeed, as you have seen all modules build files only import the common build file, and defines their dependencies in their ivy files (which you should begin to be familiar with).

So, here are some aspects of this common build file:

ivy settings

+
+<!-- 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 ivysettings file
<ivy:settings file="${common.dir}/ivysettings.xml" id="ivy.instance" />
--> +
+ +This declaration configures ivy only by setting two properties: the location for the local repository and the location for the shared repository. It's the only settings done here, since ivy is configured by default to work in a team environment (see default settings tutorial for details about this). For sure in a real environment the shared repository location would rather be in a team shared directory (or in a more complex repository, again see the default settings tutorial to see how to use something really different).
Commented out you can see how the settings would have been done if the default settings wasn't ok for our purpose.

resolve dependencies

+
+<target name="resolve" depends="clean-lib, load-ivy" description="--> resolve and retrieve dependencies with ivy">
<mkdir dir="${lib.dir}"/> <!-- not usually necessary, ivy creates the directory IF there are dependencies -->

<!-- the call to resolve is not mandatory, retrieve makes an implicit call if we don't -->
<ivy:resolve file="${ivy.file}"/>
<ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" />
</target> +
+You should begin to be familiar with this kind of use of Ivy. We call resolve explicitly to use the ivy file configured (the default would have been fine), and then call retrieve to copy resolved dependencies artifacts from the cache to a local lib directory. The pattern is also used to name the artifacts in the lib dir with their name and extension only (without revision), this is easier to use with an IDE, the IDE configuration won't change when the artifacts version change.

ivy-new-version

+
+<target name="ivy-new-version" depends="load-ivy" unless="ivy.new.revision">
<!-- default module version prefix value -->
<property name="module.version.prefix" value="${module.version.target}-dev-b" />

<!-- asks to ivy an available version number -->
<ivy:info file="${ivy.file}" />
<ivy:buildnumber
organisation="${ivy.organisation}" module="${ivy.module}"
revision="${module.version.prefix}" defaultBuildNumber="1" revSep=""/>
</target> +
+This target is used to ask Ivy to find a new version for a module. To get detailed about the module we are dealing with, we use directly the information found in the ivy file using the ivy:info task. Then the buildnumber task is used to get a new revision, based on a prefix we set with a property, by default it will be 1.0-dev-b (have a look at the default value for module.version.target in the common build properties file). Each module build by this common build file could easily override this by either setting a different module.version.target in its module specific build.properties, or even overriding module.version.prefix. To get the new revision Ivy scans the repository to find the latest available version with the given prefix, and increment this version by 1.

publish

+
+<target name="publish" depends="clean-build, jar" description="--> publish this project in the ivy repository">
<ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
resolver="shared"
pubrevision="${version}"
status="release"
/>
<echo message="project ${ant.project.name} released with version ${version}" />
</target> +
+This target publishes the module in the shared repository, with the revision found in the version property, which is set by other targets (based on ivy-new-version we have seen above). It can be used when a module reaches a specific milestone, or whenever you want the team to benefit from a new version of the module.

publish-local

+
+<target name="publish-local" depends="local-version, jar" description="--> publish this project in the local ivy repository">
<ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
resolver="local"
pubrevision="${version}"
pubdate="${now}"
status="integration"
forcedeliver="true"
/>
<echo message="project ${ant.project.name} published locally with version ${version}" />
</target> +
+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.

clean-local

+
+<target name="clean-local" description="--> cleans the local repository for the current module">
<delete dir="${ivy.local.default.root}/${ant.project.name}"/>
</target> +
+This target is used when you don't want to use your local version of a module anymore, for example when you release a new version to the whole team, or discard your local changes and want to take advantage of a new version from the team.

report

+
+<target name="report" depends="resolve" description="--> generates a report of dependencies">
<ivy:report todir="${build.dir}"/>
</target> +
+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 here with the graphml file you will find in
projects/console/build/
after having called report in the console project, and that's it, you have a clear overview of all your app dependencies !

Playing with the projects

+To play with this tutorial you can use regular ant commands. Begin in the base directory of the tutorial (src/example/multi-project), and run ant -p: +
+[ivy@apache:/ivy/multi-project]$ ant -p
+Buildfile: /ivy/multi-project/build.xml
+
+Main targets:
+
+ clean        clean tutorial: delete repository, ivy cache, and all projects
+ clean-all    clean all projects
+ publish-all  compile, jar and publish all projects in the right order
+
+
+ +This gives you an idea of what you can do here. To make sure you have at least one version of all your modules published in your repository (required to build modules having dependencies on the others), you can run ant publish-all (example log here).

You will see that Ivy calls the publish target on all the modules, following the order of the dependencies, so that a dependee is always built and published before its depender. Feel free to make changes in the source code of a module (changing a method name for instance) and in the module using the method, then call publish-all to see how the change in the dependee is compiled first, published, and then available to the depender which can compile successfully.

Then you can go in one of the example project directory (like projects/find for instance), and run ant -p: +
+[ivy@apache:/ivy/multi-project/projects/find]$ ant -p
+Buildfile: /ivy/multi-project/projects/find/build.xml
+
+Main targets:
+
+ clean          --> clean the project
+ clean-build    --> clean the project built files
+ clean-lib      --> clean the project libraries directory (dependencies)
+ clean-local    --> cleans the local repository for the current module
+ compile        --> compile the project
+ jar            --> make a jar file for this project
+ publish        --> publish this project in the ivy repository
+ publish-local  --> publish this project in the local ivy repository
+ report         --> generates a report of dependencies
+ resolve        --> resolve and retrieve dependencies with ivy
+ run            --> compile and run the project
+Default target: compile
+
+
+ +You can see the targets available, thanks to the import of the common.xml build file. Pay with the project by calling resolve, publish, and see what happens when you do the same in other projects. An interesting thing to do for instance is to change the dependencies of a project: if the module version now depends on a new commons library, you will see that all other projects depending on version will get this library as part of their transitive dependencies once the new revision of the version project is published. Very easy! And if a project introduces a change with which the depender is incompatible yet, you can very easily change the dependency in the depender to move from latest.integration to a fixed version with which the depender is compatible (probably the latest before the change). Keeping your modules under control is now very easy!

You should then be pretty familiar with multi project development with Ivy, we hope you wil l appreciate its power and flexibility! And those tutorials are only the beginning of your journey with Ivy, browse the reference documentation to learn more about the features, subscribe to the mailing lists to share your experience and ask questions with the community, browse the source code, open jira issues, submit patches, join in and help make Ivy the best dependency management tool! +
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/tutorial/multiproject.html ------------------------------------------------------------------------------ svn:mime-type = text/plain Added: ant/ivy/site/target/history/2.2.0-rc1/tutorial/start.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/tutorial/start.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/tutorial/start.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/tutorial/start.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,245 @@ + + + + + + + + +Quick Start | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Quick Start

+
In this example, we will see one of the easiest way to use Ivy. With no specific settings, Ivy uses the maven 2 repository to resolve the dependencies you declare in an Ivy file. Let's have a look at the content of the files involved.

You'll find this tutorial's sources in the ivy distribution in the src/example/hello-ivy directory.

The ivy.xml file

+This file is used to describe the dependencies of the project on other libraries.
Here is the sample: +
+<ivy-module version="2.0">
<info organisation="org.apache" module="hello-ivy"/>
<dependencies>
<dependency org="commons-lang" name="commons-lang" rev="2.0"/>
<dependency org="commons-cli" name="commons-cli" rev="1.0"/>
</dependencies>
</ivy-module> +
+ +The format of this file should pretty easy to understand, but let's give some details about what is declared here. First, the root element ivy-module, with the version attribute used to tell Ivy which version of Ivy this file use.

Then there is an info tag, which is used to give information about the module for which we are defining dependencies. Here we define only the organization and module name, you are free to choose whatever you want for them, but we recommend avoiding spaces for both of them.

Finally, the dependencies section let you define dependencies. Here this module depends on two libraries: commons-lang and commons-cli. As you can see we use the org and name attribute to define the organization and module name of the dependencies we need. The rev attribute is used to specify the revision of the module you depend on.

To know what to p ut in these attributes, you need to know the exact information for the libraries you depend on. Ivy uses the maven 2 repository by default. We recommend you use mvnrepository.com to look for the module you want. Once you find it, you will have the details on how to declare the dependency in a maven POM. For instance: +
+<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.0</version>
</dependency> +
+To convert this into an Ivy dependency declaration, all you have to do is use the groupId as organization, the artifactId as module name, and the version as revision. That's what we did for the dependencies in this tutorial, that is commons-lang and commons-cli. Note that having commons-lang and commons-cli as organization is not the best example of what the organization should be. It would be better to use org.apache, org.apache.commons or org.apache.commons.lang. However, this is how these modules are identified in the maven 2 repository, so the simplest way to get them is to use the details as is (you will see in Building a repository that you can use namespaces to redefine these names if you want something cleaner).

If you want more details on what you can do in Ivy files, you can have a look at the Ivy files reference documentation.

The build.xml file

+The corresponding build file contains a set of targets, allowing to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project.
You can use the standard "ant -p" to get the list of available targets. Feel free to have a look at the whole file, but here is the part relevant to dependency resolution: +
+<project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run">

...

<!-- =================================
target: resolve
================================= -->
<target name="resolve" description="--> retrieve dependencies with ivy">
<ivy:retrieve />
</target>
</project> +
+As you can see, it's very easy to call Ivy to resolve and retrieve dependencies: all you need if Ivy is properly installed is to define an XML namespace in your Ant file (xmlns:ivy="antlib:org.apache.ivy.ant"). Then all the Ivy ant tasks will be available in this namespace.

Here we use only one task: the retrieve task. With no attributes, it will use default settings and look for a file named ivy.xml for dependency definition. That's exactly what we want, so we need nothing more than that.

Note that in this case we define a "resolve" target and call the retrieve task. This may sound confusing, actually the retrieve task performs a resolve (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of th ose file in a local project directory). Check the How does it work ? page for details about that.

Running the project

+Ok, now that we have seen the files involved, let's run the sample to see what happens. Open a shell (or command line) window, and enter the hello-ivy example directory.
Then, at the command prompt, run 'ant': +
+[ivy@apache:/ivy/hello-ivy]$ ant 
+Buildfile: /ivy/hello-ivy/build.xml
+
+resolve:
+[ivy:retrieve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/ ::
+[ivy:retrieve] :: loading settings :: url = jar:file:///home/ivy/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
+[ivy:retrieve] :: resolving dependencies :: org.apache#hello-ivy;working@apache
+[ivy:retrieve] 	confs: [default]
+[ivy:retrieve] 	found commons-lang#commons-lang;2.0 in public
+[ivy:retrieve] 	found commons-cli#commons-cli;1.0 in public
+[ivy:retrieve] 	found commons-logging#commons-logging;1.0 in public
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar ...
+[ivy:retrieve] .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
+[ivy:retrieve] ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ (467kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (4056ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar ...
+[ivy:retrieve] ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ (245kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(source) (2621ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar ...
+[ivy:retrieve] ........................................................................................................................................................................................................................................................................................................................................... (165kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar (1809ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jar ...
+[ivy:retrieve] ........................................................ (29kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-cli#commons-cli;1.0!commons-cli.jar (1638ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0-javadoc.jar ...
+[ivy:retrieve] ............................................................................................................................................................................................. (92kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-cli#commons-cli;1.0!commons-cli.jar(javadoc) (2403ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0-sources.jar ...
+[ivy:retrieve] ...................................................................................................... (48kB)
+[ivy:retrieve] .. (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-cli#commons-cli;1.0!commons-cli.jar(source) (2106ms)
+[ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-logging/commons-logging/1.0/commons-logging-1.0.jar ...
+[ivy:retrieve] ........................................... (21kB)
+[ivy:retrieve] ... (0kB)
+[ivy:retrieve] 	[SUCCESSFUL ] commons-logging#commons-logging;1.0!commons-logging.jar (1825ms)
+[ivy:retrieve] :: resolution report :: resolve 9314ms :: artifacts dl 16520ms
+[ivy:retrieve] 	:: evicted modules:
+[ivy:retrieve] 	commons-lang#commons-lang;1.0 by [commons-lang#commons-lang;2.0] in [default]
+	---------------------------------------------------------------------
+	|                  |            modules            ||   artifacts   |
+	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
+	---------------------------------------------------------------------
+	|      default     |   4   |   3   |   3   |   1   ||   7   |   7   |
+	---------------------------------------------------------------------
+[ivy:retrieve] :: retrieving :: org.apache#hello-ivy
+[ivy:retrieve] 	confs: [default]
+[ivy:retrieve] 	7 artifacts copied, 0 already retrieved (1069kB/62ms)
+
+run:
+    [mkdir] Created dir: /ivy/hello-ivy/build
+    [javac] /ivy/hello-ivy/build.xml:53: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
+    [javac] Compiling 1 source file to /ivy/hello-ivy/build
+     [java] standard message : hello ivy !
+     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !
+
+BUILD SUCCESSFUL
+Total time: 28 seconds
+
+
+

What happened ?

+Without any settings, Ivy retrieves files from the maven 2 repository. That's what happened here.
The resolve task has found the commons-lang and commons-cli modules in the maven 2 repository, identified that commons-cli depends on commons-logging and so resolved it as a transitive dependency. Then Ivy has downloaded all corresponding artifacts in its cache (by default in your user home, in a .ivy2/cache directory). Finally, the retrieve task copies the resolved jars from the ivy cache to the default library directory of the project: the lib dir (you can change this easily by setting the pattern attribute on the retrieve task).

You might say that the task took a long time just to write out a "Hello Ivy !" message. But remember that a lot of time was spent downloading the required files from the web. Let's try to run it again: +
+[ivy@apache:/ivy/hello-ivy]$ ant 
+Buildfile: /ivy/hello-ivy/build.xml
+
+resolve:
+[ivy:retrieve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/ ::
+[ivy:retrieve] :: loading settings :: url = jar:file:///home/ivy/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
+[ivy:retrieve] :: resolving dependencies :: org.apache#hello-ivy;working@apache
+[ivy:retrieve] 	confs: [default]
+[ivy:retrieve] 	found commons-lang#commons-lang;2.0 in public
+[ivy:retrieve] 	found commons-cli#commons-cli;1.0 in public
+[ivy:retrieve] 	found commons-logging#commons-logging;1.0 in public
+[ivy:retrieve] :: resolution report :: resolve 203ms :: artifacts dl 16ms
+[ivy:retrieve] 	:: evicted modules:
+[ivy:retrieve] 	commons-lang#commons-lang;1.0 by [commons-lang#commons-lang;2.0] in [default]
+	---------------------------------------------------------------------
+	|                  |            modules            ||   artifacts   |
+	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
+	---------------------------------------------------------------------
+	|      default     |   4   |   0   |   0   |   1   ||   7   |   0   |
+	---------------------------------------------------------------------
+[ivy:retrieve] :: retrieving :: org.apache#hello-ivy
+[ivy:retrieve] 	confs: [default]
+[ivy:retrieve] 	0 artifacts copied, 7 already retrieved (0kB/0ms)
+
+run:
+    [javac] /ivy/hello-ivy/build.xml:53: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
+     [java] standard message : hello ivy !
+     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !
+
+BUILD SUCCESSFUL
+Total time: 1 second
+
+
+Great! the cache was used, no download was needed and the build was instantaneous.

And now, if you want to generate a report detailing all the dependencies of your module, you can call the report target, and check the generated file in the build directory. You should obtain something looking like this.

As you can see, using Ivy to resolve dependencies stored in the maven 2 repository is extremely easy. Now you can go on with the next tutorials to learn more about how to use module configurations which is a very powerful Ivy specific feature. Other tutorials are also available where you will learn how to use Ivy settings to leverage a possibly complex enterprise repository. It may also be a good time to start reading the reference documentation, and especially the introd uction material which gives a good overview of Ivy. The best practices page is also a must read to start thinking about how to use Ant+Ivy to build a clean and robust build system. +
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/tutorial/start.html ------------------------------------------------------------------------------ svn:mime-type = text/plain Added: ant/ivy/site/target/history/2.2.0-rc1/use/artifactproperty.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/use/artifactproperty.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/use/artifactproperty.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/use/artifactproperty.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,160 @@ + + + + + + + + +artifactproperty | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

artifactproperty

+ +
since 1.1
+Sets an ant property for each dependency artifacts previously resolved.

since 2.0 This is a post resolve task, with all the behaviour and attributes common to all post resolve tasks.

Please prefer the use of retrieve + standard ant path creation, which make your build more independent from ivy (once artifacts are properly retrieved, ivy is not required any more).

The property name and value are generated using the classical pattern concept, all artifact tokens and ivy variables being available.

since 2.0 This tag will follow the ant usual behavior for properties. If a property of the same name already exist, it's value will be unchanged. This behavior can be changed using the 'overwrite' attribute.
WARNING : Before 2.0, the behavior was to overwrite the properties. Since 2.0, the default is to not overwrite to properties


Attributes

+ + + + + + + + + + + + + + + + + + +
AttributeDescriptionRequired
namea pattern used to generate the name of the properties to setYes
valuea pattern used to generate the value of the properties to setYes
confa comma separated list of the configurations for which properties should be setNo. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
haltonfailuretrue to halt the build on ivy failure, false to continueNo. Defaults to true
validatetrue to force ivy files validation against ivy.xsd, false to force no validationNo. Defaults to default ivy value (as configured in configuration file)
settingsRefA reference to the ivy settings that must be used by this task (since 2.0)No, 'ivy.instance' is taken by default.
overwriteOverwrite the value of the property if it already exist (since 2.0). Before 2.0, the properties were always overwritten.No, 'false' by default.
+ +

Example

+Suppose we have one dependency called mydep in revision 1.0 publishing two artifacts: foo.jar and bar.jar.
Then: +
+<artifactproperty conf="build" 
name="[module].[artifact]-[revision]"
value="${cache.dir}/[module]/[artifact]-[revision].[ext]"/> +
+will set two properties: +
+mydep.foo-1.0 = my/cache/dir/mydep/foo-1.0.jar
mydep.bar-1.0 = my/cache/dir/mydep/bar-1.0.jar +
+ + +
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/use/artifactproperty.html ------------------------------------------------------------------------------ svn:mime-type = text/plain