Sign in

E-mail *, (xx@domain.com)
Password *

Register | Forgot password

Blogs

Recent blogs

RSS - Blogs
March 9, 2010
State of OSGi in the Java world
March 4, 2010
Reach more people with Google Translate
March 3, 2010
Get My Advice
February 26, 2010
What? Where!?!
February 11, 2010
Split it!

All Blogs...


Maven secrets: assembling a WCB zip

April 14, 2008

Time for part two in the Maven secrets series! This post is about using assembly  to create a zip distribution of your WCB. Not a secret really, but it may proof to be a major time saver when you are working on WCB projects.

WCB distribution guidelines

The official WCB development guidelines define that a WCB must be distributed as a zip archive that contains several additional (documentation) resources. Obviously this is not required to build and run your project, but when you want to certify the WCB or publish it on WCMExchange this is what you need to do. In short the guidelines define the following minimal layout:

     /bin             contains the WCB
     /doc             contains the javadoc
     /readme.txt      readme file
     /changelog.txt   changelog file

Wouldn't is be nice if this could be filtered and packaged all in one go? Well, guess what..

The default WCB Maven project

When creating a WCB in the SDK by default you use a standard Maven project, as  defined by the archetype, with packaging type osgi-bundle. This means that during the build packaging will be handled by the Apache Felix OSGi plugin that will create a valid OSGi bundle that can be deployed into the GX WebManager OSGi runtime. This is very nice because it saves a lot of manual labor, but it does not provide you with a complete zip distribution. You need the additional resources and then put it all together. Doing that by hand would be... well silly.

Generating javadoc on the fly

A small sidestep. Before we can start building the zip distribution we need to have the additional resources present in the build somewhere. Let have a quick look at how to do that.

First, the readme.txt and changelog.txt are resources that need to be maintained by hand (although you can obviously filter them during build time to substitude version numbers etc). Put them in the source tree somewhere. I will assume that they are under src/main/doc in the following examples.

Second, the javadoc has to be generated. You may do that in advance by calling the javadoc plugin by hand, but here is how you attach this to the standard package phase so that it will be generated on the fly when you package your project.

<project...>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <artifactId>maven-javadoc-plugin</artifactId>
        <executions>
          <execution>
            <id>create-javadocjar</id>
            <phase>compile</phase>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>

Note: due to a small inheretence problem in the standard WCB parent pom, for now, you will have to add the following snippet as well.This is a known issues and reported under GXWM-4679.

<project...>
  ...
  <reporting>
  ...
    <plugins>
  ...
      <plugin>
        <artifactId>maven-javadoc-plugin</artifactId>
      </plugin>
  ...
    </plugins>
  ...
  </reporting>
  ...
</project...>
Creating the WCB distribution

Now that we have our documentation recources in place let's go back to creating the zip file distribution. The process of creating binary distributions in Maven is called assembly and this is used throughout default maven packaging. However, it is also possible to configure custom assemblies and, as with any plugin, you may attach executions of this plugin to standard lifecycle phases.

First, you need to define the assembly. This is done in a seperate xml descriptor file that we'll put in our project under src/main/assembly/dist-assembly.xml. Below you an examples of this minimal assembly descriptor is shown.

<assembly>
  <id>dist</id>
  <formats>
      <format>zip</format>
  </formats>
  <includeBaseDirectory>false</includeBaseDirectory>
  <includeSiteDirectory>false</includeSiteDirectory>
  <fileSets>
    <!-- include and filter text files -->
    <fileSet>
      <directory>src/main/doc</directory>
      <filtered>true</filtered>
      <useStrictFiltering>true</useStrictFiltering>
      <outputDirectory>/</outputDirectory>
      <includes>
        <include>changelog.txt</include>
        <include>readme.txt</include>
      </includes>
    </fileSet>
    <!-- include and do not filter javadoc -->
    <fileSet>
      <directory>target</directory>
      <filtered>false</filtered>
      <outputDirectory>doc</outputDirectory>
      <includes>
        <include>${pom.artifactId}-${pom.version}-javadoc.jar</include>
      </includes>
    </fileSet>
    <!-- include and do not filter WCB jar -->
    <fileSet>
      <directory>target</directory>
      <filtered>false</filtered>
      <outputDirectory>bin</outputDirectory>
      <includes>
        <include>${pom.artifactId}-${pom.version}.jar</include>
      </includes>
    </fileSet>
  </fileSets>
</assembly>

Finally, all you need to do is to configure the assembly plugin to perform this assembly and attach it to the build lifecycle so that it gets executed on the fly. To do so simply add the following code to the pom file.

<project...>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <executions>
          <execution>
            <id>assemble-zip</id>
            <phase>package</phase>
            <goals>
              <goal>attached</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <descriptors>
            <descriptor>src/main/assembly/dist-assembly.xml</descriptor>
          </descriptors>
        </configuration>
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>
Conclusion

By attaching javadoc generation and assembly to the default package phase of the Maven build lifecycle and defining an assembly descriptor a WCB distribution zip is now created on the fly from the build. Obvisouly this is just a basic example. You might consider to tweak it a little by putting this in a seperate profile so that is does not get executed at each package phase? Give it a try and you'll see how flexible Maven really is!

Happy coding
Bram

About the Author

Return to all blogs


Bram de Kruijff is Product Architect and one of the co-architects of the GX WebManager framework with a focus on OSGi and services framework. Bram is part of the NAF Web 2.0 forum group to define standards on community technologies.

Read all Brams blog entries

Other blog entries:

June 26, 2009
Presentation at NAF Insight WEB 2.0
April 21, 2009
GX WebManager 9.8 on Java SE 6: The right stuff!
April 17, 2009
dOSGi talk at JSpring 2009
March 5, 2009
Accessing services in GX WebManager
June 3, 2008
A few SDK tips & tricks
May 29, 2008
Maven secrets: Dynamic Maven properties with Beanshell
May 27, 2008
GX WebManager on SpringSource Application Platform
May 9, 2008
JavaOne 2008 wrapup
April 11, 2008
ApacheCon EU 2008 impressions
April 4, 2008
OSGi techtalk at JTeam


Share:

del.icio.us
digg
Technorati
Slashdot
Reddit
YahooMyWeb
NewsVine
ekudos
© 2010 GX creative online development B.V.

Disclaimer

This website (GXdeveloperweb.com) may discuss or contain opinions, (sample) coding, software or other information that does not include GX official interfaces, instructions or guidelines and therefore is not supported by GX. Changes made based on this information are not supported.  GX will not be held liable for any damages caused by using or misusing the information, software, instructions, code or methods suggested on this website, and anyone using these methods does so at his/her own risk. GX offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this website, including any liability resulting from incompatibility between the content of this website and the materials and services offered by GX. By using this website you will not hold, or seek to hold, GX responsible or liable with respect to the content of this website.