A maven plugin to repackage your java archives : jaroverlay-maven-plugin

In the Java EE 5 Tutorial “Development Roles” chapter we can see the following three roles, from the code to the deployment :

• Application Component Provider: “The application component provider is the company or person who creates web components, enterprise beans, applets, or application clients for use in Java EE applications.”
• Application Assembler: “The application assembler is the company or person who receives application modules from component providers and assembles them into a Java EE application EAR file.”
• Application Deployer and Administrator: “The application deployer and administrator is the company or person who configures and deploys the Java EE application …”

This page says that this is the Application Assembler job to configure the deployment descriptor before packaging the EAR.

Beside that, artifact produced by mavenized enterprise projects are EARs, already packaged. Plus, it often is the developer (or Application Component Provider) that write the packaging configuration.

Next comes the “configuration for deployment” time. Here, if deployment dependant configuration is in deployment descriptors you would have to unpack the EAR and possibly nested java archives (WARs and/or JARs) to get a hand on all deployment descriptors.

This task can be quite cumbersome and time consuming (really dumb too).

I’ve read about people using maven profiles to build several EARs with different configuration but this means that the different configurations are hosted in the development project and so are released at the same time. I needed a way to have the development project contains only development and testing configuration and have deployment specific configurations hosted in a separate project that have its own release lifecycle.

I wrote jaroverlay-maven-plugin to address this need. It’s another simple maven plugin that can take an existing maven artifact and apply an overlay to it. Here is an example configuration that add/remove/replace files inside an EAR and it’s nested java archives :

 <build>
  <plugins>
   <plugin>
    <groupId>org.n0pe.mojo</groupId>
    <artifactId>jaroverlay-maven-plugin</artifactId>
    <version>0.1-SNAPSHOT</version>
    <executions>
     <execution>
     <id>ear</id>
     <goals><goal>jaroverlay</goal></goals>
     <phase>package</phase>
     <configuration>
      <overlay>
       <source>
        <groupId>org.n0pe.mojo.examples</groupId>
        <artifactId>ear-example</artifactId>
        <version>0.1-SNAPSHOT</version>
        <type>ear</type>
       </source>
       <classifier>custom-packaging</classifier>
       <puts>
        <put>
         <from>src/main/resources/test.txt</from>
         <to>war-example-0.1-SNAPSHOT.war|WEB-INF/test.txt</to>
        </put>
        <put>
         <from>src/main/resources/test.txt</from>
         <to>ejb-example-0.1-SNAPSHOT.jar|META-INF/test/txt</to>
        </put>
       </puts>
       <removes>
        <remove>war-example-0.1-SNAPSHOT.war|index.jsp</remove>
        <remove>war-example-0.1-SNAPSHOT.war|WEB-INF/lib/commons-lang-2.3.jar|META-INF/NOTICE.txt</remove>
       </removes>
      </overlay>
     </configuration>
    </execution>
   </executions>
  </plugin>
 </plugins>
</build>


When writing a path to a file contained by a nested archive, use a pipe (“|”) to inform the plugin that it has to navigate inside a nested archive.

I did not released the 0.1 as the current code is more a proof of concept than anything. It is working well for file operations. I need to clean the code up and add support for directories operations and the 0.1 will be out.

The project is hosted at google code : http://code.google.com/p/jaroverlay-maven-plugin/