Ivy is a quite abstract tool, in the sense that is focused on its tasks without getting into irrelevant details. This is probably one of its biggest adoption difficulties, as it lacks specific guidelines on some of its elements.

For example, what is a dependency type? What should it be used for? How? Is it related to the file extension?

Ivy does not care much about what do you use an artifact type for. As long as something is a type for you, Ivy handles it accordingly. It can be aligned with the file extension or not. We must remark here that Ivy has a specific attribute for the artifact file extensions. That extension attribute take the artifact type value if its not specified explicitly.Ivy does not care much about what do you use an artifact type for. As long as something is a type for you, Ivy handles it accordingly. It can be aligned with the file extension or not. We must remark here that Ivy has a specific attribute for the artifact file extensions. That extension attribute take the artifact type value if its not specified explicitly.

The Arousa template projects package files using zip archives. We use to refer to them as “transformations” because we use it for transformation sources. You are free to refer to it with the name that make more sense for you. The template projects adds the content from the doc folder to the published packages to make some sort of documentation available in the dependent projects. It may be useful for sharing details about some css rules, or maybe how should we call xslts, their names and use cases, etc.

There may be cases where the documentation contents may need to be handled with different delivery cycles. We are going to use this use case to illustrate artifact types.

We have added an example (dita-sources example) where we share several dita source sets chained. If you check for example the dita-sources-1 project you may notice a modification of the arousa build where we pack a doc zip explicitly.

<target name="arousa-package-doc"  if="${doc.folder.present}" >
 <mkdir dir="temp-doc" />
 <mkdir dir="temp-doc/doc" />
 <mkdir dir="temp-doc/doc/${arousa.project.name}" />
 <copy todir="temp-doc/doc/${arousa.project.name}" >
 <fileset dir="doc" >
 <include name="**" /> 
 <exclude name="deps/**" />
 </fileset>
 </copy>
 <!-- .......... Creating temporary doc ........... -->
 <zip destfile="dist/${arousa.project.name}-doc.zip" >
 <zipfileset dir="temp-doc"  >
 <include name="**" /> 
 </zipfileset>
 </zip>
 <delete dir="temp-doc" failonerror="false" />
 </target>

We have also added a complementary publication to the conf/arousa-ivy.xml

<publications>
    <artifact name="dita-sources-1" type="transformations" 
              ext="zip" conf="default"/>
    <artifact name="dita-sources-1-doc" type="documentation" 
              ext="zip" conf="default"/>
</publications>

We’ve also added the type to the repository pattern in the conf/arousa-ivy-settings.xml.

<property name="demo-arousa-pattern"
	    value="[organisation]/[module]/[type]/[revision]/
                                  [module]-[revision].[ext]"
	    override="true" />

Once the configurations have been adjusted, and some contents have been added to the doc folder, you can pack the contents and publish the examples. We are going to use the ant targets directly with the following command.

$ ant package dist

At this point you can retrieve and use the contents from a second or third project. Take a look at the conf/arousa-ivy.xml second dita-sources project. We have added the dependency with only the documentation artifact.

<dependencies defaultconf="default">
    <dependency org="org.markupuk.examples.vionta" 
                        name="dita-sources-1" rev="1.0" >
    <artifact name="dita-sources-1-doc" type="documentation" 
                                              ext="zip" />
</dependency>
 ...

If you type the following command you should bring the dependency to your project.

$ arousa update-dependencies

This example shows an interesting point about what can and should we use dependency management for. We can use dependency management for software binaries, code, etc. but we can also describe elements, like content, datasets and shared resources. There are several cases where this approach can be used, like for example the legal clauses that may be added to each contract, proposal, books, etc. in a publishing or in a rfp process. Usually interrelated elements that our process depend on and are shared as resources on a timely basis, both managed by different groups or used in different contexts.