To round out our exploration of the assembly descriptor, we should
touch briefly on two other sections:
containerDescriptorHandlers
and
componentDescriptors
. The
containerDescriptorHandlers
section refers to custom
components that you use to extend the capabilities of the Assembly
plugin. Specifically, these custom components allow you to define and
handle special files which may need to be merged from the multiple
constituents used to create your assembly. A good example of this might
be a custom container-descriptor handler that merged
web.xml
files from constituent war or war-fragment
files included in your assembly, in order to create the single
web-application descriptor required for you to use the resulting
assembly archive as a war file.
The componentDescriptors
section allows you to
reference external assembly-descriptor fragments and include them in the
current descriptor. Component references can be any of the
following:
-
Relative file paths:
src/main/assembly/component.xml
-
Artifact references:
groupId:artifactId:version[:type[:classifier]]
-
Classpath resources:
/assemblies/component.xml
Incidentally, when resolving a component descriptor, the Assembly plugin tries those different strategies in that exact order. The first one to succeed is used.
Component descriptors can contain many of the same
content-oriented sections available in the assembly descriptor itself,
with the exception of moduleSets
, which is considered
so specific to each project that it’s not a good candidate for reuse.
Also included in a component descriptor is the
containerDescriptorHandlers
section, which we briefly
discussed above. Component descriptors cannot contain formats, assembly
id’s, or any configuration related to the base directory of the assembly
archive, all of which are also considered unique to a particular
assembly descriptor. While it may make sense to allow sharing of the
formats section, this has not been implemented as of the 2.2-beta-2
Assembly-plugin release.