New and noteworthy
Documentation
A new introduction tutorial as simple as 1-2-3
It has never been so easy to try Ivy! You don't even need to install it yourself! Follow this simple steps and you're done:
- make sure you have ant 1.6.2 or greater and a jdk properly installed
- copy [[svn:src/example/go-ivy/build.xml this build file]] in an empty directory on your local filesystem (and make sure you name it build.xml)
- open a console in this directory and run "ant". That's it!
If you have any trouble, check the
FAQ, it may be related to your internet connection (proxy anyone?).
Want to try more tutorials? Check the [[doc:tutorial tutorials]] page in the documentation.
Offline documentation greatly improved
The offline documentation has been greatly improved, and is now a real copy of the online documentation, with all the navigation between pages as on the online version. Continue to use the online version when you can to have the latest updated version with user comments.
Documentation update
As usual, the documentation has been extensively updated with to reflect the new features. Some are still missing, but we will finish the update before the 1.4 release.
Moreover, more examples have been added, more links between the pages, and some very useful pages have been added like the [[doc:bestpractices best practices]] one.
Core features
[[doc:concept Extra attributes]]
Several tags in ivy xml files are now extensible with extra attributes.
The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns for example.
Example:
Here is an ivy file with the attribute 'color' set to blue:
Then you can use the extra attribute when you declare a dependency on foo:
And you can define your repository pattern as:
${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
Note that in order to use extra attributes, you will need to disable ivy file validation, since your files won't fulffill anymore the official ivy xsd. See the [[doc:configuration/conf configuration doc page]] to see how to disable validation.
[[doc:ivyfile/dependency Version matchers]]
Ivy now rely on a new concept to specify which version of a dependency should be used: pluggable version matchers.
This means that you can define your own way to match a dependency version.
Both latest.integration and latest sub version (1.3+ for instance) have been ported to this mechanism.
With this new feature Ivy also comes with two new built-in version matchers:
- latest.[any status]
selects the latest revision of the dependency module with at least the specified status.
- version ranges
You can now express your version contraint as a mathematical range.
Examples:
Will find the latest version of bar which is in milestone or release status.
Matches any revision greater than 1.0 and lower than 2.0, inclusive.
[[doc:ivyfile/dependency-artifact URL attribute on artifact to improve ease of use]]
The artifact tag used when declaring a dependency now supports an url attribute. Even if this should be used only in very special cases (because it derrogates to the standard repository management), it can be useful, well, in very special cases :-)
Example:
[[doc:ivyfile/conf Module configurations enhancements]]
Several improvements have been made on the module configurations:
- It is now possible to disable transitivity for a whole configuration.
Example:
- You can use
*
, *(public)
or *(private)
as wildcards to extend a set of configurations.
Example:
- You can use
*, !A, !B
in configurations mapping to mean all configurations but A and B.
Example:
[[doc:concept Events and triggers]]
Ivy now fires events all along the dependency resolution process, which can be listened and which can trigger events.
Example:
Triggers an ant build just before resolving a dependency with a latest.integration revision.
New Resolvers
[[doc:resolver/vfs vfs]]
The new vfs resolver leverages the work from
apache commons vfs to give a uniform access to a set of different file systems including ftp, sftp, webdav, zip, ...
Example:
[[doc:resolver/ssh ssh]] and [[doc:resolver/sftp sftp]]
The new ssh and sftp resolvers allow, as their name suggest, to access a repository using ssh or sftp. The secured nature of ssh and its wide spread implementation on most *nix servers makes these resolvers very good candidate in an enterprise environment.
Example:
Configuration files
[[doc:configuration/statuses Configurable statuses]]
The list of statuses available in module files is now configurable.
Example:
[[doc:configuration/module Per module settings]]
It is now possible possible to configure conflict-manager per module set.
Example:
[[doc:concept Checksums]]
Ivy now allow to use checksums to verify the correctness of a downloaded file.
For the moment Ivy supports md5 and sha1 algorithm.
The configuration of using md5 and/or sha1 can be done globally or by dependency resolver.
Globally, use the ivy.checksums variable to list the check to be done (only md5 and sha1 are supported).
On each resolver you can use the checksums attribute to override the global setting.
The setting is a comma separated list of checksum algorithm to use.
During checking (at download time), the first checksum found is checked, and that's all. This means that if you have a "sha1, md5" setting, then if ivy finds a sha1 file, it will compare the downloaded file sha1 against this sha1, and if the comparison is ok, it will assume the file is ok. If no sha1 file is found, it will look for a md5 file. If none is found no checking is done.
During publish, all listed checksum algorithms are computed and uploaded.
By default checksum algorithms are "sha1, md5".
[[doc:configuration/resolvers Fail when no module descriptor is found]]
By default when ivy doesn't find a module descriptor for a module, it lloks for an artifact, and if it finds one it assumes a default module descriptor.
It is now possible to configure this behaviour per resolver, by setting the allownomd attribute to false you can force the use of a module descriptor, and fail if none is found. This is also useful to improve performances on a resolver for which you know you will always have module descriptors.
System properties
All java system properties are now available as ivy variables in your configuration files.
Thus you can now easily define the default cache relative to user home (using ${user.home}), or access any specific property set via the standard java system property mechanism.
[[doc:configuration/resolvers Changing pattern]]
You can now define a changingPattern and a changingMatcher to configure a set of revisions which should always be considered as changing one (artifacts are checked to see if they are up to date).
The pattern and the matcher name are attributes available on all built-in resolvers.
Example:
will consider all modules with a revision ending by SNAPSHOT to be changing revisions.
[[doc:configuration/classpath Customisable classpath]]
You can now add jars to use to load plugins directly in ivy configuration, so that you can easily use your plugins in several execution environment (ant, standalone, IDE plugin, ...).
Example:
Ant tasks
[[doc:use/repreport repreport]]
A new repreport task allows to generate reports directly from your repository. The graph generation is the most interesting one, it can gives you a good overview of the dependencies between of all your modules available in your repository, or restrict this graph to just the modules from this organisation, and so on.
Example:
will generate a graphml of dependencies with all modules in the organisation "myorg"
[[doc:use/artifactreport artifactreport]]
A new artifactreport task has been introduced to easily generate an xml report with artifacts resolved, with useful information such as their original location. This report is particularly well suited for generating IDE classpaths (see also the
links page for higher IDE integration via plugins).
The generated report looks like this:
C:/home/jstuyts/data/ivy/local/hippo/sant-classes/1.01.00b04-dev/sant-classes-src-1.01.00b04-dev.zip
C:/home/jstuyts/data/ivy/cache/hippo/sant-classes/zips/sant-classes-src-1.01.00b04-dev.zip
lib/test/sant-classes-src-1.01.00b04-dev.zip
http://repository.hippocms.org/maven/testng/jars/testng-4.6.1-jdk15.jar
C:/home/jstuyts/data/ivy/cache/testng/testng/jars/testng-4.6.1-jdk15.jar
lib/test/testng-4.6.1-jdk15.jar
[[doc:use/info info]]
The new info task eases the access to some essential data contained in an ivy file without performing a dependency resolution.
Example:
[[doc:use/listmodules listmodules]]
The new listmodules task let you list modules available in the repository and set ant properties accordingly.
Example:
[[doc:use/findrevision findrevision]]
This new task sets an ant property with the latest revision found for a given module matching a given revision constraint.
[[doc:use/resolve useOrigin]]
The resolve, cachepath, and retrieve tasks now supports a new useOrigin attribute, which allow to use the original location of local artifacts instead of their location in ivy cache. Used directly on a resolve or when no resolve has been done, it will avoid the copy of the artifact to the cache, and use directly the artifact from its original location.
[[doc:use/resolve Disable transitive dependencies on resolve]]
You can now disable transitive dependencies on resolve.
Example:
[[doc:use/retrieve Synchronization feature in retrieve]]
The retrieve task can now performs a real synchronization of the destination directory, instead of a simple copy.
Example:
Standalone mode
Application launcher
Ivy can now be used as an application launcher:
java fr.jayasoft.ivy.Main -conf path/to/myivyconf.xml -dependency bar foo 2.0 -main org.bar.foo.FooMain
calls ivy with given ivyconf file and resolve bar foo 2.0, and then run org.foo.FooMain class with the resolved artifacts (foo 2.0 and its dependencies) as classpath