11 Replies Latest reply on Apr 26, 2012 9:34 AM by nwallman

    Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)

    ringerc

      I think an Arquillian example is needed in the very early intro documentation that shows:

       

      - Correct placement of beans.xml and persistence.xml in a WebArchive (though IMO the API needs to improve so ShrinkWrap "knows" where these descriptors should live in different archive types)

      - Loading persistence.xml using the descriptors module and changing the JNDI datasource to a test datasource

      - Loading beans.xml and activating an alternative bean for testing

      - Using the maven dependency resolver to load the pom.xml and then add an artifact to the ShrinkWrap web archive without having to repeat the version already specified in the pom

      - (Once supported) using @DataSourceDefinition to create an application-scoped test datasource inside the test archive

       

      These are the basic kinds of things many people will need to do when actually trying to use Arquillian and ShrinkWrap to test their own code. Right now the maven dependency resolver and the descriptors module are severely under-documented and not strongly referenced from the main docs, so it takes a lot of time wasting to find them and find out how to use them correctly.

       

      Any thoughts?

       

      I've written an example that satisfies most of the points above as part of a self contained test case for some bugs I just submitted against Arquillian and ShrinkWrap. I'm happy to document it a bit and make it available - any suggestions on how to go about that? I've attached a preliminary version that's still lacking most of the required documentation.

       

      (Edit: Replaced attachment with one updated to reference Arquillian 1.0.0.Final and the new descriptors api)

       

      The attached example contains numerous notes on the Arquillian and ShrinkWrap APIs that should be cut out for use, but are retained here to bring those issues to the attention of the ShrinkWrap and Arquillian folks. JIRA issues filed are:

       

       

      Here's the updated version of the test file with maven descriptors 2.x use:

       

      package com.example.arqdemo;
      
      
      import com.example.arqdemo.Demo;
      import java.io.File;
      import javax.inject.Inject;
      import org.jboss.arquillian.container.test.api.Deployment;
      import org.jboss.arquillian.junit.Arquillian;
      import org.jboss.shrinkwrap.api.ShrinkWrap;
      import org.jboss.shrinkwrap.api.asset.StringAsset;
      import org.jboss.shrinkwrap.api.spec.WebArchive;
      import org.jboss.shrinkwrap.descriptor.api.Descriptors;
      import org.jboss.shrinkwrap.descriptor.api.beans10.BeansDescriptor;
      import org.jboss.shrinkwrap.descriptor.api.persistence10.PersistenceDescriptor;
      import org.jboss.shrinkwrap.resolver.api.DependencyResolvers;
      import org.jboss.shrinkwrap.resolver.api.maven.MavenDependencyResolver;
      import org.junit.*;
      import static org.junit.Assert.*;
      import org.junit.runner.RunWith;
      
      
      //
      // This is a small demo showing how Arquillian can be used to run tests
      // involving the java persistence API (JPA) in a container.
      //
      @RunWith(Arquillian.class)
      public class DemoTest {
      
      
          //
          // This method is called by Arquillian to create the test archive. It is
          // not run on the application server; it runs on a client-side JVM.
          //
          // All the classes referenced in the @Deployment method
          // must still be resolvable from the deployed web archive
          // because the class as a whole must be loadable
          // on the application server. That means that if you only use a library
          // within the @Deployment method you must still ensure that ShrinkWrap
          // includes it (or api stubs for it) in your test archive. ShrinkWrap and
          // Arquillian automatically provide thin api stubs for their own APIs,
          // so you don't need to worry about them.
          // 
          @Deployment
          public static WebArchive createDeployment() {
      
              // Use the Maven dependency resolver to import all our dependencies
              // If preferred, you can explicitly specify only the dependencies
              // you want using .artifacts("theGroupId:theArtifactId", ...)
              // or specify artifacts not listed in your pom by adding a :version to
              // the co-ordinates passed to .artifacts(...).
              //
              // See: 
              //  https://community.jboss.org/wiki/FAQHowToIAddMavenArtifactsToMyShrinkWrapArchives
              //
              File[] mvnLibs = DependencyResolvers.use(MavenDependencyResolver.class)
                      .loadEffectivePom("pom.xml")
                      .importAllDependencies()
                      .resolveAsFiles();
      
      
              // Load our project's beans.xml
              //
              // We can use the BeansDescriptor to make changes to the beans.xml
              // like substituting @Alternative beans, etc.
              //
              // If you just need an empty beans.xml, you can use:
              //  
              //    Descriptors.create(BeansDescriptor.class);
              //
              // instead.
              //
              // In of ShrinkWrap Descriptors 2.0.0-alpha-1, a bug prevents 
              // the addition of alternatives to an existing <alternatives/> clause.
              // See: 
              //   https://issues.jboss.org/browse/SHRINKDESC-115
              // Check for updates; a later release may have fixed this.
              //
              BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class)
                      .from(new File("src/main/webapp/WEB-INF/beans.xml"));
      
      
              //
              // Load the project's persistence.xml. As with beans.xml we could alter
              // it to, eg, switch to a testing-only JNDI datasource, but in this example
              // we're just going to copy it.
              //
              PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class)
                      .from(new File("src/main/resources/META-INF/persistence.xml"));
      
      
              //
              // Now wrap the test class, dependencies, descriptors, and the class(es) being
              // tested into an archive for deployment to the server.
              //
              return ShrinkWrap.create(WebArchive.class)
                      .addPackage(Demo.class.getPackage())
                      .addAsWebInfResource(new StringAsset(beansXml.exportAsString()), "beans.xml")
                      .addAsResource(new StringAsset(persistenceXml.exportAsString()), "META-INF/persistence.xml")
                      .addAsLibraries(mvnLibs);
          }
      
          // If beans.xml is included, CDI injection works in unit tests run on the
          // container, so we can use it to get an instance of our demo bean with
          // the EntityManager properly injected.
          //
          @Inject
          private Demo d;
      
          @Test
          public void testEntityManagerInjected() {
              assertNotNull(d);
          }
      
          @Test
          public void testBasicPersistence() {
              assertNull(d.getGarbage(1));
              d.setGarbage(1, "garbage");
              assertEquals(d.getGarbage(1), "garbage");
          }
      
          @Test
          public void testCommonsLang() {
              // Use a method that requires Apache Commons Lang 3 to function
              // just to prove that we've successfully pulled the dependency in.
              d.setGarbageToRandom(2);
              String randomGarbageString = d.getGarbage(2);
              System.err.println("Got random garbage string: " + randomGarbageString);
          }
      
      }
      

       

      There's also another file in the example that shows the order in which everything in an Arq test executes:

       

      package com.example.arqdemo;
      
      
      import org.jboss.arquillian.container.test.api.Deployment;
      import org.jboss.arquillian.junit.Arquillian;
      import org.jboss.shrinkwrap.api.ShrinkWrap;
      import org.jboss.shrinkwrap.api.spec.JavaArchive;
      import org.junit.*;
      import org.junit.runner.RunWith;
      
      
      //
      // This test demonstrates the order in which things happen in an Arquillian
      // test execution.
      // 
      // When you run this test, the client-side mesages are emitted in the
      // "mvn test" output to the console, and the server-side messages are
      // sent to the application server logs.
      //
      @RunWith(Arquillian.class)
      public class OrderingTest {
      
      
          // If it exists, this method runs on the client (outside the container)
          // It does *not* also get run in the container, at least for JUnit+Arquillian.
          @BeforeClass
          public static void runsOnClientBeforeAllTests() {
              System.err.println("BeforeClass");
          }
      
          // As @BeforeClass, runs on client
          @AfterClass
          public static void runsOnClientAfterAllTests() {
              System.err.println("BeforeClass");
          }
          @Deployment
          public static JavaArchive createDeployment() {
              System.err.println("createDeployment()");
              return ShrinkWrap.create(JavaArchive.class);
          }
      
      
          // The ctor runs once on the server for each @Test, because the whole
          // test lifecycle runs on the server for each test.
          //
          // There's no guarantee that instances of the class won't also be
          // created client-side. In general, it's best to use the annotated
          // lifecycle methods rather than the constructor.
          //
          public OrderingTest() {
              System.err.println("OrderingTest() ctor");
          }
      
          // The @Before method(s) are run on the server before each test. 
          // There is no container-side equivalent of @BeforeClass that runs
          // only once before any tests are run.
          @Before
          public void runsOnServerBeforeEachTest() {
              System.err.println("@Before");
          }
      
          @After
          public void runsOnServerAfterEachTest() {
              System.err.println("@After");
          }
      
          @Test
          public void test1() {
              System.err.println("test1()");
          }
      
          @Test
          public void test2() {
              System.err.println("test2()");
          }
      
      }
      


       

      Here's the old version of the unit test file from the example, showing all the concerns/suggestions I have re the current test API and annotated with the JIRA issues I've filed.

       

       

       

      package com.example.shrinkwraphibernatetest;
      
      import java.io.File;
      import javax.inject.Inject;
      import org.jboss.arquillian.container.test.api.Deployment;
      import org.jboss.arquillian.junit.Arquillian;
      import org.jboss.shrinkwrap.api.ShrinkWrap;
      import org.jboss.shrinkwrap.api.asset.StringAsset;
      import org.jboss.shrinkwrap.api.spec.WebArchive;
      import org.jboss.shrinkwrap.descriptor.api.Descriptors;
      import org.jboss.shrinkwrap.descriptor.api.beans10.BeansDescriptor;
      import org.jboss.shrinkwrap.descriptor.api.persistence10.PersistenceDescriptor;
      import org.jboss.shrinkwrap.resolver.api.DependencyResolvers;
      import org.jboss.shrinkwrap.resolver.api.maven.MavenDependencyResolver;
      import static org.junit.Assert.*;
      import org.junit.Test;
      import org.junit.runner.RunWith;
      
      
      @RunWith(Arquillian.class)
      public class DemoTest {
      
      
          //
          // This method is called by Arquillian to create the test archive. It is
          // not run on the application server.
          //
          // All the classes referenced in the @Deployment method
          // must still be resolvable from the deployed web archive
          // because the class as a whole must be loadable
          // on the application server. That means that if you only use a library
          // within the @Deployment method you must still ensure that ShrinkWrap
          // includes it (or api stubs for it) in your test archive. ShrinkWrap and
          // Arquillian automatically provide thin api stubs for their own APIs,
          // so you don't need to worry about them.
          // 
          @Deployment
          public static WebArchive createDeployment() {
      
              MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class)
                      // Load dependencies from our project's pom.xml
                      //
                      .includeDependenciesFromPom("pom.xml");
                      // API NOTE: ShrinkWrap should automatically do the equivalent of the following:
                      // (Created as issue https://issues.jboss.org/browse/SHRINKWRAP-395)
                      //
                      //.exclusions("org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee",
                      //            "org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven",
                      //            "org.jboss.arquillian.junit:arquillian-junit-container",
                      //            "org.jboss.as:jboss-as-arquillian-container-remote");
                      // 
                      // and provide stubs for the public API in each that just throw if
                      // called. That way none of the transitive dependencies of ShrinkWrap
                      // and Arquillian need to get included in the test archive and
                      // create possible conflicts with app server libraries.
                      //
                      // Excluding all `test' scope artifacts won't work well, because
                      // it makes it harder to include other libs that're only used in
                      // unit tests, forcing them to be explicitly declared individually
                      // to ShrinkWrap. ShrinkWrap should only exclude its own artifacts
                      // and those of Arquillian. 
                      //
                      // A jar manifest entry that says "I'm an -impl jar for ShrinkWrap
                      // or Arquillian, exclude me from test archives" might be a good way
                      // to handle this, since the use of extension resolvers/descriptors/etc
                      // means ShrinkWrap can't know an exclusive list of its own artifacts.
                      //
                      // Currently, the -impl archives all get included in test archives.
                      // The test archive for this project is over 31MB!
                      //
      
      
      
              // Load our project's beans.xml
              //
              // We can use the BeansDescriptor to make changes to the beans.xml
              // like substituting @Alternative beans, etc.
              //
              // If you just need an empty beans.xml, you can use:
              //  
              //    Descriptors.create(BeansDescriptor.class);
              //
              // instead.
              //
              // API NOTE: BeansDescriptor should know the default path to beans.xml
              // for a given archive type (as specified by <packaging/> in the pom)
              // and not need to have it specified for default Maven structure projects.
              // (Created issue https://issues.jboss.org/browse/SHRINKWRAP-396)
              //
              BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class)
                      .from(new File("src/main/webapp/WEB-INF/beans.xml"));
      
      
              //
              // Load the project's persistence.xml. As with beans.xml we could alter
              // it to, eg, switch to a testing-only JNDI datasource, but in this example
              // we're just going to copy it.
              // API NOTE: Same path issues as BeansDescriptor above.
              //
              PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class)
                      .from(new File("src/main/resources/META-INF/persistence.xml"));
      
      
              //
              // API NOTE: Some usability issues for the dependency resolver
              //  
              // DEPENDENCY RESOLVER
              // -------------------
              //
              // For the resolver, we should be able to specify only the artifacts we
              // want included in a test with, eg:
              //
              //    .addAsLibraries( resolver.artifacts("org.apache.commons:commons-lang3").resolveAsFiles() )
              //
              // ... but currently the version isn't automatically pulled from the pom if not
              // specified, so we get a bad co-ordinates error from Maven. We must pull all
              // dependencies in from the pom, or must explicitly duplicate version information
              // from the pom.
              //
              // Filed as: https://issues.jboss.org/browse/SHRINKWRAP-397
              // Possibly related to https://issues.jboss.org/browse/SHRINKWRAP-394
              //
              // SHRINKWRAP.CREATE
              // -----------------
              //
              //    ShrinkWrap.create(WebArchive.class, "blah.jar")
              // and
              //    ShrinkWrap.create(JavaArchive.class, "blah.war")
              //
              // should detect the naming error and log a warning or throw. Same for
              // other errors like .ear files. Right now, the user gets a ClassNotFoundException
              // when the test is run that's not obviously connected to the misnamed archive.
              // (Filed as https://issues.jboss.org/browse/ARQ-863)
              //
              WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
                      .addPackage(Demo.class.getPackage())
                      // API NOTE: next two lines should be .addDescriptor(...) with path auto-detected based on archive and descriptor type. See above.
                      .addAsWebInfResource(new StringAsset(beansXml.exportAsString()), "beans.xml")
                      .addAsResource(new StringAsset(persistenceXml.exportAsString()), "META-INF/persistence.xml")
                      // API NOTE: See above, should allow .artifacts("groupId:artifactId") w/o version
                      .addAsLibraries(resolver.resolveAsFiles());
      
              // API NOTE: Should have a way to retain the .war built by ShrinkWrap
              // for examination, or a way to get ShrinkWrap to write it out somewhere.
              // 
              // Currently -impl API has to be used to keep a copy of the archive, eg:
              //
              //new org.jboss.shrinkwrap.impl.base.exporter.zip.ZipExporterImpl(war)
              //         .exportTo(new File("/tmp/testarchive.war"));
              //
              // and we should instead be able to use a -api method like ".keepTestArchive()" or
              // ".writeCopyTo(...)"
              //
              // (Appears to be solved by https://issues.jboss.org/browse/ARQ-141; TODO: Add to example)
              //
              return war;
          }
      
      
          // If beans.xml is included, CDI injection works in unit tests run on the
          // container, so we can use it to get an instance of our demo bean with
          // the EntityManager properly injected.
          //
          // API NOTE: IMO, Arquillian should emit a warning if javax.inject.* annotations
          // like javax.inject.Inject are found but no beans.xml is present. Those NullPointerExceptions
          // are a PITA, especially given the different locations beans.xml must be placed in a .jar vs .war
          // and the way ShrinkWrap can't take care of that for you.
          // (See https://issues.jboss.org/browse/ARQ-867)
          //
          @Inject
          private Demo d;
      
          @Test
          public void testEntityManagerInjected() {
              assertNotNull(d);
          }
      
          @Test
          public void testBasicPersistence() {
              assertNull(d.getGarbage(1));
              d.setGarbage(1, "garbage");
              assertEquals(d.getGarbage(1), "garbage");
          }
      
          @Test
          public void testCommonsLang() {
              // Use a method that requires Apache Commons Lang 3 to function
              // just to prove that we've successfully pulled the dependency in.
              d.setGarbageToRandom(2);
              String randomGarbageString = d.getGarbage(2);
              System.err.println("Got random garbage string: " + randomGarbageString);
          }
      
      }
      

       

      Added JIRA references

        • 1. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
          aslak

          I agree, the integration between ShrinkWrap and ShrinkWrap Descriptors is a bit clunky at the moment. The 'problem' is we want them to be two separate projects, e.g. you can use Descriptors with out Archives and the other way around. So in their core apis they shouldn't depend on each other. We had a discussion a while back wether WebArchive/EnterpriseArchive should be split out from core shrinkwrap api and moved into some form of ee-api module instead. Doing that we could bind WebArchive and EnterpriseArchive tigther to Descriptors having e.g. setWebXml(WebAppDescirptor), addAsWebInfDescriptor(Descriptor)

           

          Currently there is an integration module, https://github.com/shrinkwrap/shrinkwrap-descriptors-archive-integration that tries to smoothen over it a bit, but it doesn't go far enough. It only contain a DescriptorAsset, which allow you to write, addAsWebInfResource(new DescriptorAsset(descriptor)) (without the exportAsString bit)

           

          The DescriptorAsset extend something from core api called NamedAsset, which is basically a Asset type that can bring it's own name. It's currently only supported on root level, .add(NamedAsset), and that NamedAsset only has a chance to return a single name without knowing what type of Archive it's being added to, which means it can't adjust the path for beans.xml between JavaArchive and WarArchive for instance.

           

          We definietly need to look at this integration and get it working.

           

          Maybe Arquillian could provide it's own ShrinkWrap views that is more specialized for testing and how it's used in that context, as a addon to the ShrinkWrap purer Archive vs Descirptor views..

           

          ShrinkWrap.create(ExplodedImporter.class)
            .importFrom("target/classes")
            .as(WebArchive.class)
              .getDescriptor(PersistenceDescriptor.class)
                .persistenceUnit("test-db")
              .getDescriptor(BeansDescriptor.class)
                .alternatives(MyAlternative.class)
                
          ShrinkWrap.create(WebArchive.class)
              .addDescriptor(BeansDescriptor.class)
                .alternatives(MyAlternative.class)
              .addPackage(MyModel.class.getPackage())
          
          
          • 2. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
            aslak

            - Using the maven dependency resolver to load the pom.xml and then add an artifact to the ShrinkWrap web archive without having to repeat the version already specified in the pom

             

            This is already supported in Resolver. In the 1.x series it's loadMetaDataFromPom(pom.xml)

            • 3. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
              aslak

              https://issues.jboss.org/browse/ARQ-863

               

              I would propose to log a warning in ShrinkWrap.create(), if you create a ArchiveType with a extension that is different then the 'default extension mapping' for that ArchiveType.

              Arquillian is currently checking for the View type when it does the packaging operations etc, but this should be changed to rely on extension, like the containers do.

               

              archive instanceOf WebArchive vs archive.getName().endsWith(".war")

               

              In ShrinkWrap what you are using, e.g. WebArchive is intended to be just a View of the Archive, so they are not directly tied to the Archive it self or it's content.

               

              ShrinkWrap.create(WebArchive.class).as(EntrerpriseArhcive.class) is allowed, tho it makes little sense. The intention is that you can create specialized views for more specific operations. ShrinkWrap.create(WebArchive.class).as(JBossWebArchive.class).as(PersistenceArchive.class).as(MyCompaniesSpecialView.class).addModuleX().addModuleZ() etc..

               

              But some of the view types are more 'bound' to the ArchiveType, e.g. WebArchive(.war), JavaArchive(.jar), EnterpriseArchive(.ear) and they follow the spec's definition of what a .war can contain and how it should look.

              • 4. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                ringerc

                I need to update this example to show the 2.x dependency resolver, yeah. It's working very well in my tests and is much appreciated, I just hadn't found out about it when I wrote the above because I was still going by the Arquillian 1.0.0.Final bom and docs at that point.

                • 5. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                  aslak

                  I started hacking on a possible new integration between Archives and Descriptors. Basically a new Archive View that contain the knowledge of where the Descriptors should be, tho still not a part of the Archive Type interfaces due to dependency boundries, it does play nice with the View idea that we have (but haven't really explored to much yet)

                   

                  So basically any 'Archive' can be seen as a DescriptiveArchive(need better name), where as in that view, you have the option to add or get a Descriptor. Based on the Descriptor name and the Archive extension the View known where to place / get the Descriptor from.

                   

                  The current test class that show the new API: https://gist.github.com/2473765

                   

                  API snippet:

                          WebArchive war = ShrinkWrap.create(WebArchive.class)
                                      .as(DescriptiveArchive.class)
                                          .add(Descriptors.create(BeansDescriptor.class))
                                      .as(WebArchive.class);
                    
                          Assert.assertTrue(war.contains(ArchivePaths.create("WEB-INF/beans.xml")));
                          
                          JavaArchive jar = ShrinkWrap.create(JavaArchive.class)
                                  .as(DescriptiveArchive.class)
                                      .add(Descriptors.create(BeansDescriptor.class))
                                  .as(JavaArchive.class);
                  
                           Assert.assertTrue(jar.contains(ArchivePaths.create("META-INF/beans.xml")));
                  

                   

                   

                  The current mapping table:

                          mappings.put(new TypeDescriptor("web.xml", ArchiveType.WebArchive), "WEB-INF/");
                          mappings.put(new TypeDescriptor("beans.xml", ArchiveType.WebArchive), "WEB-INF/");
                          mappings.put(new TypeDescriptor("beans.xml", ArchiveType.JavaArchive), "META-INF/");
                          mappings.put(new TypeDescriptor("application.xml", ArchiveType.EnterpriseArchive), "META-INF/");
                          mappings.put(new TypeDescriptor("persistence.xml", ArchiveType.WebArchive), "WEB-INF/classes/META-INF/");
                          mappings.put(new TypeDescriptor("persistence.xml", ArchiveType.JavaArchive), "META-INF/");
                          
                          mappings.put(new TypeDescriptor("ra.xml", ArchiveType.ResourceAdapterArchive), "META-INF/");
                          mappings.put(new TypeDescriptor("ejb-jar.xml", ArchiveType.JavaArchive), "META-INF/");
                          mappings.put(new TypeDescriptor("ejb-jar.xml", ArchiveType.WebArchive), "WEB-INF/");
                          mappings.put(new TypeDescriptor("taglib.xml", ArchiveType.WebArchive), "WEB-INF/");
                          
                          mappings.put(new TypeDescriptor("faces-config.xml", ArchiveType.WebArchive), "WEB-INF/");
                          mappings.put(new TypeDescriptor("taglibrary.tld", ArchiveType.WebArchive), "WEB-INF/");
                          
                          mappings.put(new TypeDescriptor("webfragment.xml", ArchiveType.WebArchive), "WEB-INF/"); // ??
                          mappings.put(new TypeDescriptor("webfragment.xml", ArchiveType.JavaArchive), "META-INF/");
                  
                  • 6. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                    ringerc

                    That looks like a significant improvement to me, particularly the automatic location of the files. Thanks very much for the thought put into this and for working on implementing it.

                    • 7. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                      jaikiran

                      Aslak Knutsen wrote:

                       

                      
                              mappings.put(new TypeDescriptor("webfragment.xml", ArchiveType.JavaArchive), "META-INF/");
                      

                      Minor correction - It should be web-fragment.xml

                      • 8. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                        aslak

                        Jaikiran, aa, correct.. copy/paste from Descriptors. I'll fix it upstream

                        • 9. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                          nwallman

                          In your attached examples I see you have included the 1.0 way of doing things, could up also include the example using 2.0?  I'm most interested in the pom.xml.

                          • 10. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                            ringerc

                            Nathan: 1.0 vs 2.0 of what, exactly? There are a few different things involved here.

                            • 11. Re: Proposed Arquillian/ShrinkWrap example test with descriptors, maven artifact resolution, etc (attached)
                              nwallman

                              In your first post you talk about 2 different variations of doing things.  I've been having some issues with the first approach mainly around dependency resolution with Maven.  I just wanted to give the second variation a try but I couldn't quite figure out how to get my pom.xml setup correctly.  So I wanted to look at yours for a comparison.  What you provided in the revised zip is perfect. Thanks.