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.
If building the same output as defined in your POM is the feature you’re after, why not use the “Build Importer” in ShrinkWrap Resolvers?
“ShrinkWrap.create(MavenImporter.class)
.loadPomFromFile(“/path/to/pom.xml”).importBuildOutput().as(WebArchive.class);”
All API docs for SWR in the User Guide: https://github.com/shrinkwrap/resolver/blob/master/README.asciidoc
S,
ALR
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.
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.
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.