## Jar

### Description

Jars a set of files.

The basedir attribute is the reference directory from where to jar.

Note that file permissions will not be stored in the resulting jarfile.

It is possible to refine the set of files that are being jarred. This can be done with the includes, includesfile, excludes, excludesfile and defaultexcludes attributes. With the includes or includesfile attribute you specify the files you want to have included by using patterns. The exclude or excludesfile attribute is used to specify the files you want to have excluded. This is also done with patterns. And finally with the defaultexcludes attribute, you can specify whether you want to use default exclusions or not. See the section on directory based tasks, on how the inclusion/exclusion of files works, and how to write patterns.

This task forms an implicit FileSet and supports all attributes of `<fileset>` (`dir` becomes `basedir`) as well as the nested `<include>`, `<exclude>` and `<patternset>` elements.

You can also use nested file sets for more flexibility, and specify multiple ones to merge together different trees of files into one JAR. The extended fileset attributes from the zip task are also available in the jar task. See the Zip task for more details and examples.

If the manifest is omitted, a simple one will be supplied by Ant. You should not include `META-INF/MANIFEST.MF` in your set of files.

The `update` parameter controls what happens if the JAR file already exists. When set to `yes`, the JAR file is updated with the files specified. When set to `no` (the default) the JAR file is overwritten. An example use of this is provided in the Zip task documentation.

(The Jar task is a shortcut for specifying the manifest file of a JAR file. The same thing can be accomplished by using the fullpath attribute of a zipfileset in a Zip task. The one difference is that if the manifest attribute is not specified, the Jar task will include an empty one for you.)

Manifests are processed by the Jar task according to the Jar file specification. Note in particular that this may result in manifest lines greater than 72 bytes being wrapped and continued on the next line.

### Parameters

Attribute | Description | Required
file | the jar-file to create. | Yes
basedir | the directory from which to jar the files. | No
compress | Not only store data but also compress them, defaults to true | No
encoding | The character encoding to use for filenames inside the archive. Defaults to UTF8. It is not recommended to change this value as the created archive will most likely be unreadable for Java otherwise. | No
filesonly | Store only file entries, defaults to false | No
includes | comma separated list of patterns of files that must be included. All files are included when omitted. | No
includesfile | the name of a file. Each line of this file is taken to be an include pattern | No
excludes | comma separated list of patterns of files that must be excluded. No files (except default excludes) are excluded when omitted. | No
excludesfile | the name of a file. Each line of this file is taken to be an exclude pattern | No
defaultexcludes | indicates whether default excludes should be used or not ("yes"/"no"). Default excludes are used when omitted. | No
manifest | the manifest file to use. | No
update | indicates whether to update or overwrite the destination file if it already exists. | No

### Nested elements

#### metainf

The nested `metainf` element specifies a FileSet. All files included in this fileset will end up in the `META-INF` directory of the jar file. If this fileset includes a file named `MANIFEST.MF`, the file is ignored and you will get a warning.

#### Manifest

The manifest nested element allows the manifest for the Jar file to be provided inline in the build file rather than in an external file. This element is identical to the manifest task, but its file and mode attributes will be ignored.

If both an inline manifest and an external file are both specified, the manifests are merged.

When using inline manifests, the Jar task will check whether the build file is more recent that the Jar file when deciding whether to rebuild the Jar. This will not take into account property file changes which may affect the resulting Jar.

### Examples

      <jar file="${dist}/lib/app.jar" basedir="${build}/classes"/>

jars all files in the `${build}/classes` directory into a file called `app.jar` in the `${dist}/lib` directory.

      <jar file="${dist}/lib/app.jar"
           basedir="${build}/classes"
           excludes="**/Test.class"
      />

jars all files in the `${build}/classes` directory into a file called `app.jar` in the `${dist}/lib` directory. Files with the name `Test.class` are excluded.

      <jar file="${dist}/lib/app.jar"
           basedir="${build}/classes"
           includes="mypackage/test/**"
           excludes="**/Test.class"
      />

jars all files in the `${build}/classes` directory into a file called `app.jar` in the `${dist}/lib` directory. Only files under the directory `mypackage/test` are used, and files with the name `Test.class` are excluded.

      <jar file="${dist}/lib/app.jar">
        <fileset dir="${build}/classes"
                 excludes="**/Test.class"
        />
        <fileset dir="${src}/resources"/>
      </jar>

jars all files in the `${build}/classes` directory and also in the `${src}/resources` directory together into a file called `app.jar` in the `${dist}/lib` directory. Files with the name `Test.class` are excluded. If there are files such as `${build}/classes/mypackage/MyClass.class` and `${src}/resources/mypackage/image.gif`, they will appear in the same directory in the JAR (and thus be considered in the same package by Java).

      <jar jarfile="test.jar" basedir=".">
        <include name="build"/>
        <manifest>
          <attribute name="Built-By" value="${user.name}"/>
          <section name="common/class1.class">
            <attribute name="Sealed" value="false"/>
          </section>
        </manifest>
      </jar>

This is an example of an inline manifest specification. Note that the Built-By attribute will take the value of the Ant property ${user.name}. The manifest produced by the above would look like this:

    Manifest-Version: 1.0
    Built-By: conor
    Created-By: Apache Ant 1.5alpha

    Name: common/class1.class
    Sealed: false

Copyright © 2000,2001 Apache Software Foundation. All rights Reserved.