Maven and ShrinkWrap/Arquillian made easy?


If you read this post you surely know ShrinkWrap and Maven. The main issue is the boilerplate code needed to create a WebArchive in a Maven project. This is really easier since ShrinkWrap resolver has a correct implementation of the Maven resolver but it still looks useless. All projects end with a ShrinkWrapUtil utility class to do it.

On another side TomEE provides an utility module to ease ShrinkWrap usage called ziplock. It allows you, for instance, to find a File from a class (see JarLocation) or provides you some shortcuts to create Archives (see WebModule). These utilities were created because of TomEE tests need.

However since few days it includes something more general and interesting for any maven user: the Mvn class.

It comes in two flavors:

  • static methods “war” and “testWar”: create a class using default maven configuration to create a war representing the current module (test war adds test scoped dependencies)
  • a builder “Mvn.Builder” which allows you to customize the maven defaults.

 

In the first case just call “org.apache.ziplock.maven.Mvn.war()” or “org.apache.ziplock.maven.Mvn.testWar()” to get the archive (you can continue to customize it then).

In the second case you need to create a new “Mvn.Builder” then customize it and call “build”. For instance to customize the name of the WebArchive and the maven basedir:

new Mvn.Builder().name("myapp.war").basedir(new File("..")).build();

Moreover “org.apache.ziplock.maven.PreloadableWar” (and “org.apache.ziplock.maven.PreloadableTestWar”) is just a shortcut to be able to use “preloadClasses” feature of arquillian tomee adapters – see my previous post. Once configured just call “org.apache.ziplock.maven.PreloadableTestWar.war()” in your “@Deployment” method.

Advertisements

4 thoughts on “Maven and ShrinkWrap/Arquillian made easy?

    1. rmannibucau Post author

      Hi

      Great you remind it

      The difference are: i build it before the war (more consistent imo) handling shiro integration and i can filter some files to override them without needing to merge 2 webapps. Basically a create(MavenImporter.class).filter(…) is missing to be able to remove Mvn.Builder class.

      Reply
    2. sCRYbZ

      Andrew, that’s just Awesome. Arquillian is so poorly documented that Tom-EE group made a subproject to re-implement functionality the maven shrinkwrap resolver silently had all along. Call me ungrateful for open-source if you want, but Red Hat Middleware (JBoss) should put some resources on this. Seriously, having to resort to RTFS is a documentation failboat.

      Reply
      1. rmannibucau Post author

        well tomee community didnt reimplement the whole feature but rather enriched it for mocking.

        rtfs is not as bad as it cause at least it is consistent and up to date. outdated docs are worse than anything else. open source is awesome regarding it and project tests a wonderful way to learn.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s