[Ivy Wiki] Update of "IvyUseCases" by easyproglife

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ivy Wiki" for change notification.

The following page has been changed by easyproglife:
http://wiki.apache.org/ivy/IvyUseCases

New page:
= Ivy Use Cases =

== What is this page about? ==

This page demonstrate common and possible uses of Ivy.
The main usage is of course bringing Java JAR files to a project but there may be other interesting use cases.

== 1. The most common use cases ==

The following use cases are very common and are going after Apache Maven's spirit.

 1.1 (The trivial one:) Find and bring Java JAR files needed to compile a Java project. (Known as "compile" dependency.)

 1.2 (Almost trivial as the above) Declare the runtime dependencies of a Java product in other Java JAR files. (Known as "runtime" dependency.)

 1.3 Find and bring Java JAR files needed for unit test, usually during an automatic build. (Known as "test" dependency.)

Note: these kind of dependencies (AKA 'configurations') are widely used by free open source projects around. Other kinds of dependencies are not standard and are used (or may be used) mostly internally by organizations.

== 2. Other possible and interesting use cases ==

'''2.1 Web service WSDL versioning.'''
The idea here is to create a project ('module') containing WSDL and probably XSD files needed to define a web-service. The need to version WSDL documents comes mainly during parallel development of a web-service and its client. They both depends on the WSDL document and have to explicitly know if they are using the same interface - the WSDL document.
Note: This use case could be generalized as "interface versioning". It is good not only for WSDL but also to CORBA IDL, and alike.


'''2.2 Build time properties. '''
During the build, we often need to use common properties that are the same among all the projects. For example: we want to add Vendor-Name and Vendor-URL to the JAR manifest; or we want to auto-generate Java code from XML schema with a common set of XML-namespace-to-Java-package-name mapping. For such uses, we can create an ivy module that other projects depends on, and automatically share these properties in a simple way. This is better than just using a properties file that is located 'somewhere around' (or worst: a file that is being duplicated of each and every project) since we use versioning. Using ivy.xml you can instantly know what exact version of the properties file your module had been built against. This dependency, of course, need to be declared using a separate 'configuration' in ivy.xml, in order not to be confused with the 'compile' and 'runtime' configurations.

== Other use cases ==

Note: if you are using Ivy in a different way, please share us all. The benefit would be to all of us: we would better understand what other people expect Ivy to do, and we may together develop common 'usage patterns' to address common problems in a common, easy and simple way.