Java Reference
In-Depth Information
There are some unfortunate cases in which isolation of a part of the project for the micro
deployment is not possible. You just add more and more classes to it and there is no end.
This means that your project might have a poor design, but let's say you want to introduce
Arquillian in some existing legacy project and you had no influence on its structure. In
that case, you might want to import not just some classes or packages, but the whole pro-
ject to your integration test. Some people do tricks; they just use the basic ShrinkWrap
and import a .jar or .war file using the ZipImporter ShrinkWrap:
ShrinkWrap
.create(ZipImporter.class)
.importFrom(new File("/target/myPackage.war"))
.as(WebArchive.class);
The problem is what is really in this archive? You probably import an archive created dur-
ing the previous build since it is created after finishing the tests! What's more, it cannot
even exist when you're just working from the IDE and not running the full Maven build!
It's the place where you can use the MavenImporter class. Refer to the following code:
ShrinkWrap.create(MavenImporter.class)
.loadPomFromFile("/path/to/pom.xml")
.importBuildOutput()
.as(WebArchive.class);
That's it! Internally, it runs the simplified build, gathering compiled classes and resources
and packing it to the archive. It does not run inside the complete Maven build using some
embedded instance, since that would be much too slow. You might want to add such a
method to your test utilities:
public class ArquillianWarUtils {
// already presented code
public static WebArchive getBasicWebArchive() { . . . }
public static WebArchive importBuildOutput() {
return ShrinkWrap.create(MavenImporter.class)
.loadPomFromFile("pom.xml")
.importBuildOutput()
.as(WebArchive.class);
Search WWH ::




Custom Search