Uploaded image for project: 'ShrinkWrap Resolvers'
  1. ShrinkWrap Resolvers
  2. SHRINKRES-18

MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default)

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • 2.0.0-alpha-7
    • 2.0.0-alpha-1
    • None
    • None

    Description

      Currently the MavenImporter on war files requires "mvn package" to be run every time (not only the first time), to update the exploded directory at "target/

      {finalName}

      ".
      This means if you change something in your code and want to (re)run a test,
      and forget to run "mvn package" first, you're running the old code (and the results are not representative of the changed code).

      Karel and Geoffrey discussed this at JUDCon London.
      The following things can be probably presumed:

      • The IDE compiles all classes from src/main/java to target/classes.
      • The IDE copies all non-filtered resources from src/main/resources to target/classes.
      • That target/classes is copied into the war at WEB-INF/classes.
      • Most src/main/webapp dirs are copied unaltered into the root of the war.
      • "mvn compile" is run once after any "mvn clean": in other words, all src/main/filtered-resources are in target/classes

      So MavenImporter doesn't have to require "mvn package" to build the exploded dir first (which it then zips, enriches and sends to arquillian).
      Instead, it can construct the war zip directly from target/classes and src/main/webapp.
      That is at least one less copy and more importantly, to run the test from the IDE without having to build first.

      Note: all examples above used the explicit directory locations, but in reality the pom.xml's <build> section should be used to determinate the directory locations for a certain project.

      Attachments

        Issue Links

          Activity

            People

              kpiwko Karel Piwko
              gdesmet@redhat.com Geoffrey De Smet (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: