Next, look at the EAR example. The ear-example build item directly or indirectly depends on many of the other build items we've seen so far. It also depends on a private build item, ear-example.local-jar that builds a JAR file for inclusion in the EAR file. There's nothing special about this, but making it a private build item inside of ear-example makes it clear that it is private to the EAR file:

this: ear-example
parent-dir: ..
platform-types: java
child-dirs: local-jar
deps: war-example jar-example har-example ear-example.local-jar

abuild.ear-name = ear-example.ear
abuild.application-xml = application.xml

Unlike with WAR files, EAR files actually contain the direct products produced by other build items, not their JAR counterparts: notice that the HAR and WAR files are directly contained in the EAR file:

META-INF/
META-INF/MANIFEST.MF
META-INF/application.xml
ear-code.jar
har-example.har
jar-example.jar
war-example.war

Note also that the EAR file contains the WAR file and it also directly contains some of its contents, notably the JAR and HAR files. (The HAR file is included in the WAR by a different name; the JAR file is included with the same name.) This behavior may change in the future. Also, observe that the abuild.application-xml property has to be set in Abuild-ant.properties in addition to the abuild.ear-name property in order for an EAR to be created.

Suppose you wanted to avoid inclusion of just the jar-example.jar file from the EAR file. You can do this by creating a local pre-package hook that removes it from the classpath directory. To illustrate this, we have a second EAR example in the other-ear directory. It defines a local build file and enables local hooks. Here is its Abuild-ant.properties file:

abuild.ear-name = other-ear-example.ear
abuild.application-xml = application.xml
abuild.local-buildfile = local.xml
abuild.use-local-hooks = yes

This file refers to the local build file local.xml:

<?xml version="1.0"?>

<project default="other-ear-example">

 <!--  Prevent jar-example.jar from being included in the ear.     -->
 <target name="-pre-package">
  <delete file="classpath/jar-example.jar"/>
 </target>

</project>

This same mechanism can be used to create hybrid client/server WAR files. The main problem with this approach is that it requires you to know the name of the archives you want to move or remove, though this is not as bad as knowing their locations. A comparable alternative would be to define custom interface variables in your dependencies to name the actual archives. These interface variables would be available as ant properties from your local build file.

As with a JAR file, anything in the src/conf directory will appear under src/META-INF, and anything in src/resources will appear in the EAR file relative to its location in src/resources.

The above examples illustrate how other archive types are constructed in abuild at the present time. There are several potential problems that may be addressed in a future release of abuild. For details, please see Appendix B, Known Limitations.