{extends "idf/base-simple.html"}
{block docclass}yui-t3{/block}
{block body}
<p>At the moment, this documentation is only available in English.</p>

<ul>
<li><a href="#q-motivation">Motivation</a></li>
<li><a href="#q-manifest">The manifest format</a></li>
</ul>

<h2 id="q-motivation">Motivation</h2>

<p>
Adding multiple, individual downloads to a project for a release can be a tedious task if
one has to select each file manually, and then has to fill in the summary and correct labels
for each of these downloads individually.
</p>

<p>
InDefero therefore supports the upload of "archives" that contain multiple downloadable
files. These archives are standard PKZIP files with only one special property - they
contain an additional manifest file which describes the files that should be published.
</p>

<p>
Once such an archive has been uploaded and validated by InDefero, its files are extracted
and individual downloads are created for each of them. If the archive contains files
that should replace existing downloads, then InDefero takes care of this as well -
automatically. Files that exist in the archive but are not listed in the manifest are
not extracted.
</p>

<p>
An archive file and its manifest file can easily be compiled, either by hand with the help
of a text editor, or through an automated build system with the help of your build tool of
choice, such as Apache Ant.
</p>

<h2 id="q-manifest">The manifest format</h2>

<p>
The manifest is an XML file that follows a simple syntax. As it is always easier to look
at an example, here you have one:
</p>

<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<manifest>
  <file>
    <name>foo-1.2.tar.gz</name>
    <summary>Tarball</summary>
    <replaces>foo-1.1.tar.gz</replaces>
    <labels>
       <label>Type:Archive</label>
    </labels>
  </file>
  <file>
    <name>foo-1.2-installer.exe</name>
    <summary>Windows MSI Installer</summary>
    <description>This installer needs Windows XP SP2 or later.</description>
    <labels>
       <label>Type:Installer</label>
       <label>OpSys:Windows</label>
    </labels>
  </file>
</manifest>
</pre>

<p>
This is the DTD for the format:
</p>

<pre>
<!DOCTYPE manifest [
<!ELEMENT manifest (file+)>
<!ELEMENT file (name,summary,replaces?,description?,tags?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT summary (#PCDATA)>
<!ELEMENT replaces (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT labels (label+)>
<!ELEMENT label (#PCDATA)>
]>
</pre>

<p>
The format is more or less self-explaining, all fields map to properties of a single download.
One special element has been introduced though, <code>replaces</code>. If this optional element
is given, InDefero looks for a file with that name in the project and acts in one of the following
two ways:
</p>

<ul>
<li>If the new file's name is distinct from the file's name that is given in <code>replaces</code>,
then the replaced file is <strong>marked as deprecated</strong> with the <code>Other:Deprecated</code> label
(or any other label that is configured as the very last label in the download project configuration).</li>
<li>If the new file's name is equal to the file's name that is given in <code>replaces</code>,
then the replaced file <strong>is deleted</strong> before the new file is created. This happens because each file name
has to be unique per project and a deprecated and a new file with the same name cannot coexist in InDefero.
Note that while the filename-based URI of the download keeps intact, the download counter will be reset by
this procedure.</li>
</ul>

If no existing file is found for the <code>replaces</code> tag, then this is completely ignored.
</p>
{/block}

{block context}
<p>{trans 'Here we are, just to help you.'}</p>
<h2>{trans 'Projects'}</h2>
<ul>{foreach $projects as $p}
<li><a href="{url 'IDF_Views_Project::home', array($p.shortname)}">{$p}</a></li>
{/foreach}</ul>
{/block}