ShrinkWrap: How to replace a file in an artifact resolved with MavenDependencyResolver.

gistfile1.java

public static WebArchive getTestPreparedArchive() {
    WebArchive war = ShrinkWrap.create(WebArchive.class, "service.war")
            .addClasses(MyClass1.class, MyClass2.class); // add classes needed for the test

    // Resolve the needed dependency independently, so we can replace the production persistence.xml inside the archive
    Collection<JavaArchive> archives = DependencyResolvers.use(MavenDependencyResolver.class)
            .artifact("se.diabol.persistence:Persistence_Framework:jar:0.1-SNAPSHOT").resolveAs(JavaArchive.class);

    // Resolve the actual archive
    JavaArchive p = null;
    for (JavaArchive jar : archives) {
        if (jar.getName().equals("Persistence_Framework-0.1-SNAPSHOT.jar")) {
            p = jar;
            break;
        }
    }
    if (p == null)
        throw new IllegalStateException("Could not resolve desired artifact");

    // Replace production persistence.xml with test context version
    p.delete("/META-INF/persistence.xml");
    p.add(new ClassLoaderAsset("test-persistence.xml"), "/META-INF/persistence.xml");

    // Add the manipulated dependency to the test archive
    war.addAsLibrary(p);
    return war;
}

Some classes I'm about to test with Arquillian depends on an EJB jar which I can fetch from a local Maven repository. But I need to manipulate that archive so I can make sure a persistence.xml suitable for the test context (with e.g. in-memory database) is included instead of the one intended for production. The question is, is there an easier way to this?

Sounds like you want to resolve WITHOUT transitivity to get just "se.diabol.persistence:Persistence_Framework:jar:0.1-SNAPSHOT", then muck around with that single returned archive, right?

In this case yes. Guess I could instruct the MavenDependencyResolver not to bring in the transitive dependencies. But would there be any difference to the approach if I would need to bring in some of the the EJB jars dependencies as well in another case, other than adding those libraries as well?

Sorry, I'm not understanding your last sentence?

Also keep in mind that the shiny new SWR 2.0 API is coming soon, which looks more like this:

final JavaArchive archive = ShrinkWrapMaven.resolver().resolve("G:A:V").withoutTransitivity()
        .asSingle(JavaArchive.class);

Also keep in mind that the shiny new SWR 2.0 API is coming soon, which looks more like this:

final JavaArchive archive = ShrinkWrapMaven.resolver().resolve("G:A:V").withoutTransitivity()
        .asSingle(JavaArchive.class);

And by "soon", I mean "now": http://exitcondition.alrubinger.com/2012/09/13/shrinkwrap-resolver-new-api/

Cool, now thats good news! What I was trying to say was, in this case I do not need transitive dependencies, but sometimes I do, depending on what I'm testing. It would be convenient if I could delete an asset and add a new one (as the persistence.xml in this case) directly from the DSL, without having to create intermediate/temporary objects.