Created
September 12, 2012 13:00
-
-
Save tommysdk/3706436 to your computer and use it in GitHub Desktop.
ShrinkWrap: How to replace a file in an artifact resolved with MavenDependencyResolver.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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; | |
} |
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?