blob: f7c8ba927f2f3b53e38da3b6eb25756d4adbee80 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<script type="text/javascript">var xookiConfig = {level: 1};</script>
<script type="text/javascript" src="../xooki/xooki.js"></script>
</head>
<body>
<textarea id="xooki-source">
<span class="since">since 2.4</span>
The <tt>fixdeps</tt> task serializes transitively resolved dependencies into an ivy.xml file.
The dependencies declared in an ivy.xml can be specified as range of revisions. And the transitive dependencies too. As new versions of modules can be added to the repository anytime, resolved versions of ranges can change over time. It is then safer to resolve a range once and stick with the resolved revision. This way a resolve process is highly reproductible.
It is especially useful in a very dynamic environment like the <a href="../osgi.html">OSGi</a> one.
In a multi project environment some dependencies still need to be maintained loose: the one between the projects. These dependencies, as soon as they are declared in the original ivy.xml, can be kept from being fixed. In order to do so, use the inner element <tt>keep</tt>.
The recommended setup is then to:
<ul>
<li>have an <tt>ivy-spec.xml</tt> in your project which specifies the dependencies, with ranges if needed</li>
<li>have an Ant target which resolve the <tt>ivy-spec.xml</tt> and call <tt>fixdeps</tt> to generate an <tt>ivy.xml</tt>. This target should then only be called after <tt>ivy-spec.xml</tt> is modified. The generated <tt>ivy.xml</tt> can safely be shared in a version control repository (svn, git,...).</li>
<li>make the entire build workflow based on the resolve of the generated <tt>ivy.xml</tt></li>
</ul>
This is a [[ant:postresolvetask post resolve task]], with all the behaviour and attributes common to all post resolve tasks.
<h1>Attributes</h1>
<table class="ant">
<thead>
<tr><th class="ant-att">Attribute</th><th class="ant-desc">Description</th><th class="ant-req">Required</th></tr>
</thead>
<tbody>
<tr><td>tofile</td><td>The location of the ivy file to generate</td>
<td>Yes</td></tr>
</tbody>
</table>
<h1>Child elements</h1>
<table class="ant">
<thead>
<tr><th class="ant-att">Element</th><th class="ant-desc">Description</th><th class="ant-req">Cardinality</th></tr>
</thead>
<tbody>
<tr><td>keep</td><td>declares a dependency to keep from being fixed, and keep its original declaration from the original ivy.xml
<br/>These elements takes two attributes: <ul><li>org</li> the organization<li>module</li>the name of the module</ul></td>
<td>0..n</td></tr>
</tbody>
</table>
<h1>Examples</h1>
<code type="xml">
<ivy:fixdeps tofile="ivy-fixed.xml" />
</code>
Simple fix of some dependencies.
<hr/>
<code type="xml">
<ivy:fixdeps tofile="ivy-fixed.xml">
<keep org="com.acme" module="mymodule" />
</ivy:fixdeps>
</code>
Fix of the dependencies but keep the dependency on <tt>com.acme#mymodule</tt> as defined in the original ivy.xml.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>