-
15. Re: Arquillian Design Questions:
Hold on, option 2 is perfect and does not require the artifact to be physically built and installed somewhere first. It simply requires ShrinkWrap to automatically include the entire main classpath. The tester then only has to explicitly list the test classes that are active for that test. This is a fantastic option for many use-cases. (In fact, if you use option 1, you are already specifying the classes to be used in setup boilerplate somewhere in the test itself (depending on the framework being used)).
(Sorry, Dan this is perhaps what you were originally intending for option 2. When you said "test against the project artifact" and "publishing the artifact", I thought you were referring to the build system (eg: maven) physically building the artifact first (a deal-breaker for IDE productivity). However, you probably were referring to ShrinkWrap ).
I only have time for a short response, but exactly!! I'm excited that we are on the same page now. And accomplishing this goal shouldn't be too difficult. We will bring it up in the design discussion on Monday and layout out a plan.
-
16. Re: Arquillian Design Questions:
Playing around with the MavenEmbedder lib..
{code:java}
public class MavenArtifactArchiveImplTest { @Test public void shouldBeAbleToAddMavenArtifact() throws Exception { MavenArtifactArchive archive = Archives.create("test.jar", MavenArtifactArchive.class); archive.addLibrary(MavenArtifact.of("org.jboss.shrinkwrap", "shrinkwrap-api")); archive.addLibrary(MavenArtifact.of("org.jboss.shrinkwrap", "shrinkwrap-impl-base")); archive.addLibrary(MavenArtifact.of("org.apache.maven", "maven-embedder")); JavaArchive jar = archive.as(JavaArchive.class); System.out.println(jar.toString(Formatters.FULL)); // validate added paths Assert.assertTrue(jar.contains(ArchivePaths.create("maven-embedder-2.0.4.jar"))); Assert.assertTrue(jar.contains(ArchivePaths.create("shrinkwrap-api-1.0.0-SNAPSHOT.jar"))); Assert.assertTrue(jar.contains(ArchivePaths.create("shrinkwrap-impl-base-1.0.0-SNAPSHOT.jar"))); } }
{code}{code}test.jar: /maven-embedder-2.0.4.jar /shrinkwrap-api-1.0.0-SNAPSHOT.jar /shrinkwrap-impl-base-1.0.0-SNAPSHOT.jar{code}What it does:
- loads up a pom
- search for runtime dependencies that match the given groupid/artifactid
- add it to the archive as a FileAsset
Some issues with the current impl:
- Assumes pom.xml file in working directory
- Does not resolve dependencies to added library
- Due to current ShrinkWrap extension loading we can not rely an a existing LibraryContainer
- webArchive.as(MavenArtifactArchive.class) { // should result in a new MavenArtifactArchive(webArchive) }. MavenArtifactArchive(LibraryContainer)
-
-
19. Re: Arquillian Design Questions:
Karel Piwko has done some work for us here.
https://github.com/shrinkwrap/shrinkwrap/pull/3
I've created a branch for us to sync work here:
https://github.com/shrinkwrap/shrinkwrap/tree/SHRINKWRAP-140
Both Aslak and I have made some minor changes and did a code review.
- The dependency trees in src/test/resources are pretty involved, and suck in things like ARQ and ShrinkWrap, which constitutes a cyclic dependency. Let's make these simpler, and relying only on things available in Maven Central (as we're going to move to Maven Central after Beta1).
- Aether dependency upgrade breaks the tests. PomDependenciesUnitTestCase.testPomRemoteBasedDependencies asserts on its own POM.
- Let's create a local repo in src/test/resources. This will give us a strictly-controlled environment from which to pull. All tests should be configured to use this repo alone. It shouldn't need to be too heavily-populated; just enough to carry out the tests.
- "mvn clean install" takes 4.5m. If we have an already-built repo under target, this goes to ~45s. The above bullet should help keep test execution down as we're not recreating repos.
S,
ALR
