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 most 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 and groupfileset child elements from the zip task are also available in the jar task. See the Zip task for more details and examples.

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. Please note that ZIP files store file modification times with a granularity of 2 seconds. If a file is less than 2 seconds newer than the entry in the archive, Ant will not consider it newer.

If the manifest is omitted, a simple one will be supplied by Apache Ant.

The whenmanifestonly parameter controls what happens when no files, apart from the manifest file, or nested services, match. If skip, the JAR is not created and a warning is issued. If fail, the JAR is not created and the build is halted with an error. If create (default), an empty JAR file (only containing a manifest and services) is created.

(The Jar task has 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.

The Jar task checks whether you specified package information according to the versioning specification.

Please note that the ZIP format allows multiple files of the same fully-qualified name to exist within a single archive. This has been documented as causing various problems for unsuspecting users. If you wish to avoid this behavior you must set the duplicate attribute to a value other than its default, add.

To cryptographically sign your JAR file, use the SignJar task on the JAR that you create from this task.

For creating a simple version of a JEP 238 multi-release jar, you don't need any special tools. Just set the required manifest entry and place the files where required, as you could see in the JEP 238 example. If you want to tune this kind of jar, e.g. decreasing the size by deleting 'same' classes from the versions-branches, you have to do more ...

Parameters

Parameters specified as 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 nested manifest 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 the file and mode attributes must be omitted.

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 manifest contents have changed (i.e. the manifest as specified is different in any way from the manifest that exists in the jar, if it exists. If the manifest values have changed, the jar will be updated or rebuilt, as appropriate.

indexjars

Since Ant 1.6.2

The nested indexjars element specifies a path-like structure. Its content is completely ignored unless you set the index attribute of the task to true.

The index created by this task will contain indices for the archives contained in this path, the names used for the archives depend on your manifest:

• If the generated jar's manifest contains no Class-Path attribute, the file name without any leading directory path will be used and all parts of the path will get indexed.
• If the manifest contains a Class-Path attribute, this task will try to guess which part of the Class-Path belongs to a given archive. If it cannot guess a name, the archive will be skipped, otherwise the name listed inside the Class-Path attribute will be used.

This task will not create any index entries for archives that are empty or only contain files inside the META-INF directory unless the indexmetainf attribute has been set to true.

indexjarsmapper

Since Ant 1.10.9

The nested indexjarsmapper element can be used to perform custom filename transformations for the archives specified by indexjars if the default filename transformation doesn't suffice.

service

Since Ant 1.7.0

The nested service element specifies a service. Services are described in the service provider overview. The approach is to have providers JARs include files named by the service provided, for example, META-INF/services/javax.script.ScriptEngineFactory which can include implementation class names, one per line (usually just one per JAR).

The name of the service is set by the type attribute. The classname implementing the service is the the provider attribute, or if one wants to specify a number of classes that implement the service, by provider nested elements.

The provider classname is specified either by the provider attribute, or by a nested <provider> element, which has a single classname attribute. If a JAR file has more that one implementation of the service, a number of nested <provider> elements may be used.

Examples

Simple

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

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

With filters

Jar 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 destfile="${dist}/lib/app.jar"
     basedir="${build}/classes"
     excludes="**/Test.class"/>

Jar 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 destfile="${dist}/lib/app.jar"
     basedir="${build}/classes"
     includes="mypackage/test/**"
     excludes="**/Test.class"/>

Multiple filesets

Jar 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 destfile="${dist}/lib/app.jar">
    <fileset dir="${build}/classes"
             excludes="**/Test.class"/>
    <fileset dir="${src}/resources"/>
</jar>

Merging archives

Create an executable jar file with a main class com.acme.checksites.Main, and embed all the classes from the jar lib/main/some.jar.

<jar destfile="build/main/checksites.jar">
    <fileset dir="build/main/classes"/>
    <zipfileset includes="**/*.class" src="lib/main/some.jar"/>
    <manifest>
      <attribute name="Main-Class"
                 value="com.acme.checksites.Main"/>
    </manifest>
</jar>

Create an executable jar file with a main class com.acme.checksites.Main, and embed all the classes from all the jars in lib/main.

<jar destfile="build/main/checksites.jar">
    <fileset dir="build/main/classes"/>
    <restrict>
       <name name="**/*.class"/>
       <archives>
           <zips>
               <fileset dir="lib/main" includes="**/*.jar"/>
           </zips>
       </archives>
    </restrict>
    <manifest>
        <attribute name="Main-Class"
              value="com.acme.checksites.Main"/>
    </manifest>
</jar>

Inline manifest

<jar destfile="test.jar" basedir=".">
    <include name="build"/>
    <manifest>
        <!-- If this is an Applet or Web Start application, include
             the proper attributes from https://docs.oracle.com/javase/8/docs/technotes/guides/jweb/index.html -->
        <attribute name="Permissions" value="sandbox"/>
        <attribute name="Codebase" value="example.com"/>
        <!-- Who is building this jar? -->
        <attribute name="Built-By" value="${user.name}"/>
        <!-- Information about the program itself -->
        <attribute name="Implementation-Vendor" value="ACME inc."/>
        <attribute name="Implementation-Title" value="GreatProduct"/>
        <attribute name="Implementation-Version" value="1.0.0beta2"/>
        <!-- details -->
        <section name="common/MyClass.class">
            <attribute name="Sealed" value="false"/>
        </section>
    </manifest>
</jar>

This is an example of an inline manifest specification including the version of the build program (Implementation-Version). 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
Permissions: sandbox
Codebase: example.com
Built-By: conor
Implementation-Vendor: ACME inc.
Implementation-Title: GreatProduct
Implementation-Version: 1.0.0beta2
Created-By: Apache Ant 1.9.2

Name: common/MyClass.class
Sealed: false

Service Provider

The following shows how to create a jar file specifying a service with an implementation of the scripting interface:

<jar destfile="pinky.jar">
    <fileset dir="build/classes"/>
    <service type="javax.script.ScriptEngineFactory"
             provider="org.acme.PinkyLanguage"/>
</jar>

The following shows how to create a jar file specifying a service with two implementations of the scripting interface:

<jar destfile="pinkyandbrain.jar">
    <fileset dir="classes"/>
    <service type="javax.script.ScriptEngineFactory">
        <provider classname="org.acme.PinkyLanguage"/>
        <provider classname="org.acme.BrainLanguage"/>
    </service>
</jar>

JEP 238 example: a Multi-Release JAR Files

Here we want to create a Multi-Release JAR File according the specification JEP 238. It defines on top of a JAR the possibility to place additional or overwriting classes in a jar, which are available according to the Java version you run.
Basically it says, that you have to set the manifest entry Multi-Release: true and place all additional or overwriting classes in META-INF/versions/number/package-structure, e.g. META-INF/versions/9/org/apache/ant/MyClass.class

In this example we expect that the normal classes are compiled into ${java.classes} and the Java 9 classes are compiled into ${java9.classes}.

<jar destfile="mrjar.jar">
    <manifest>
        <!-- special mf-entry according to the spec -->
        <attribute name="Multi-Release" value="true"/>
    </manifest>
    <!-- directory structure according to the spec ... -->
    <!-- ... default classes loadable by old (<Java 9) versions -->
    <fileset dir="${java.classes}"/>
    <!-- ... per release classes, require Java 9+ for loadable via standard ClassLoader -->
    <zipfileset prefix="META-INF/versions/9/" dir="${java9.classes}"/>
</jar>