[ https://jira.jboss.org/jira/browse/ARQ-74?page=com.atlassian.jira.plugin.... ] Pete Muir updated ARQ-74: ------------------------- Component/s: Packaging Enricher SPI -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ARQ-74?page=com.atlassian.jira.plugin.syste... ] Aslak Knutsen updated ARQ-74: ----------------------------- Fix Version/s: 1.0.0.Alpha4 (was: 1.0.0.Alpha3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ARQ-74?page=com.atlassian.jira.plugin.syste... ] Aslak Knutsen updated ARQ-74: ----------------------------- Fix Version/s: 1.0.0.CR1 (was: 1.0.0.Beta1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ARQ-74?page=com.atlassian.jira.plugin.sys... ] Dan Allen commented on ARQ-74: ------------------------------ This topic recently came up in the Testing SIG in the thread "Testing deployment of pre-built .war to various web servers" - https://community.jboss.org/message/730868#730868 The current state of affairs / workaround, as Marek pointed out, is {code:java} ShrinkWrap.create(ZipImporter.class, "foo.war").importFrom(new File("target/foo.war")) {code} The caveat is that you have to make sure your test runs in the integration-test maven phase, that is after "package". That workaround, however, is at odds with the goal of the Arquillian project, which is to skip the build when testing. In that thread, I proposed an annotation that would build a deployment (using ShrinkWrap Resolvers) based on the current project's artifact. Here's how it would be used: {code:java} @RunWith(Arquillian.class) @DeployProjectArtifact public class MyFunctionalTest { @ArquillianResource private URL url; @Test public void shouldBehaveSomeWay() { // make a request to the url } } {code} Of course, in this case, a @Deployment method would not be required (which is possible through an extension). I had hacked up an extension prototype a while back that implements this idea, though it uses the older ShrinkWrap Resolver...which would be replaced by the new ShrinkWrap Resolver APIs, which are being discussed in this forum thread: https://community.jboss.org/message/731735 https://gist.github.com/2477705 According to Karel: {quote} Now we have a ShrinkWrap Resolver Maven Plugin, @DeployProjectArtifact might work without specifying path to the pom, active profiles, etc. However, IDE support for the plugin is still an open question here. This is an actual show-stopper for the moment https://issues.jboss.org/browse/SHRINKRES-18. If implemented, creating an Arquillian extension with @DeployProjectArtifact annotation would be an easy task. {quote} Karel also suggested that this annotation should be a part of ShrinkWrap Maven Resolver. Once on classpath, you can do Maven magic for deployments. Alternate names for the annotation are as follows: * @DeployBuildOutput * @DeployProjectArchive I prefer either "project artifact" or "project archive" since it's not just the output, but rather the package that the build is creating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira