March 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-115) Create Importer API bridge to SW

by Bernard Labno (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-115?page=com.atlassian.jira.plu... ] Bernard Labno commented on SHRINKRES-115: ----------------------------------------- John, Arquillian should have soon long awaited featured to load all test into single archive and do one deployment for all test classes. With this approach we can easily waste some time for building the package with maven. Main reason is for acceptance tests. Arq praises itself for doing real tests, but unless the tests are run against almost exact same package as the one that will be used on production they are still just fakes. So we really need to have package built exactly the same as Maven would build it. Other reason is that sometimes it's not as easy to build an archive as copying source files to a jar file. Sometimes those files require heavy processing. And this is when we should use EmbeddedMavenImporter and let real Maven to build the archive. Light MavenImporter by SW is still great option for simple cases. > Create Importer API bridge to SW > -------------------------------- > > Key: SHRINKRES-115 > URL: https://issues.jboss.org/browse/SHRINKRES-115 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Reporter: Andrew Rubinger > Assignee: Bernard Labno > > Use case as prototyped by [~blabno]: > {code} > final JavaArchive archive = ShrinkWrap.create(EmbeddedMavenImporter.class, > "jar-with-excludes.jar").loadPomFromFile( > "src/it/jar-sample/pom.xml").importBuildOutput().as(JavaArchive.class); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-115) Create Importer API bridge to SW

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-115?page=com.atlassian.jira.plu... ] John Ament commented on SHRINKRES-115: -------------------------------------- Bernard, I guess my biggest question is why do you need to kick off an entire build every time you want to test? > Create Importer API bridge to SW > -------------------------------- > > Key: SHRINKRES-115 > URL: https://issues.jboss.org/browse/SHRINKRES-115 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Reporter: Andrew Rubinger > Assignee: Bernard Labno > > Use case as prototyped by [~blabno]: > {code} > final JavaArchive archive = ShrinkWrap.create(EmbeddedMavenImporter.class, > "jar-with-excludes.jar").loadPomFromFile( > "src/it/jar-sample/pom.xml").importBuildOutput().as(JavaArchive.class); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-115) Create Importer API bridge to SW

by Bernard Labno (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-115?page=com.atlassian.jira.plu... ] Bernard Labno commented on SHRINKRES-115: ----------------------------------------- John, I do not understand #1. Maven is very extensible tool. People use filters, customize plugins, etc. I.e. RichFaces use maven plugin to pack together and compress all css and js files. So sometimes we actually need to some maven goals or phases to get artifacts that should be used and tested. Here is output of some options of mvn --help. {code} usage: mvn [options] [<goal(s)>] [<phase(s)>] Options: -am,--also-make If project list is specified, also build projects required by the list -amd,--also-make-dependents If project list is specified, also build projects that depend on projects on the list -B,--batch-mode Run in non-interactive (batch) mode -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match -D,--define <arg> Define a system property -f,--file <arg> Force the use of an alternate POM file. -gs,--global-settings <arg> Alternate path for the global settings file -N,--non-recursive Do not recurse into sub-projects -npu,--no-plugin-updates Ineffective, only kept for backward compatibility -nsu,--no-snapshot-updates Suppress SNAPSHOT updates -o,--offline Work offline -P,--activate-profiles <arg> Comma-delimited list of profiles to activate -pl,--projects <arg> Comma-delimited list of specified reactor projects to build instead of all projects. A project can be specified by [groupId]:artifactId or by its relative path. -s,--settings <arg> Alternate path for the user settings file {code} I think that the API should allow: 1) setting profiles and properties ("like mvn -DskipTests=true ..."). 2) toggle online/offline 3) invoke phase or goalsetting phase 4) select pom file Optional stuff I'm not sure of is: 5) select settings file 6) select global settings file 7) strict/lax checksums 8) am/amd 9) non-recursive 10) global-settings file 11) settings file 12) npu/nsu 13) --projects > Create Importer API bridge to SW > -------------------------------- > > Key: SHRINKRES-115 > URL: https://issues.jboss.org/browse/SHRINKRES-115 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Reporter: Andrew Rubinger > Assignee: Bernard Labno > > Use case as prototyped by [~blabno]: > {code} > final JavaArchive archive = ShrinkWrap.create(EmbeddedMavenImporter.class, > "jar-with-excludes.jar").loadPomFromFile( > "src/it/jar-sample/pom.xml").importBuildOutput().as(JavaArchive.class); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-444) Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-444?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on SHRINKWRAP-444: ---------------------------------------------------- thradec(a)redhat.com made a comment on [bug 918442|https://bugzilla.redhat.com/show_bug.cgi?id=918442] verified in shrinkwrap-1.1.2 > Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used > -------------------------------------------------------------------------------------------------- > > Key: SHRINKWRAP-444 > URL: https://issues.jboss.org/browse/SHRINKWRAP-444 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.1.1 > Reporter: Tomas Hradec > Assignee: Andrew Rubinger > Priority: Critical > Fix For: 1.1.2 > > > How to reproduce: > This bug appeared when deploying war archive into EAP 6.0.1. The archive was created by `ShrinkWrap.createFromZipFile(WebArchive.class, new File("path to war"))`. And it has to contain embedded library, which size is greater than few kilobytes, on tiny sizes it didn't appear. > My test archive has following structure and size 670kB. > {code} > test.war: > /WEB-INF/ > /WEB-INF/lib/ > /WEB-INF/lib/hsqldb-1.8.0.10.jar > /WEB-INF/web.xml > /WEB-INF/classes/ > /WEB-INF/classes/org/ > /WEB-INF/classes/org/jboss/ > /WEB-INF/classes/org/jboss/wfk/ > /WEB-INF/classes/org/jboss/wfk/test/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/HelloWorldServlet.class > {code} > Stack trace: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:148) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:91) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) > ... 88 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-444) Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-444?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on SHRINKWRAP-444: ---------------------------------------------------- thradec(a)redhat.com changed the Status of [bug 918442|https://bugzilla.redhat.com/show_bug.cgi?id=918442] from NEW to VERIFIED > Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used > -------------------------------------------------------------------------------------------------- > > Key: SHRINKWRAP-444 > URL: https://issues.jboss.org/browse/SHRINKWRAP-444 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.1.1 > Reporter: Tomas Hradec > Assignee: Andrew Rubinger > Priority: Critical > Fix For: 1.1.2 > > > How to reproduce: > This bug appeared when deploying war archive into EAP 6.0.1. The archive was created by `ShrinkWrap.createFromZipFile(WebArchive.class, new File("path to war"))`. And it has to contain embedded library, which size is greater than few kilobytes, on tiny sizes it didn't appear. > My test archive has following structure and size 670kB. > {code} > test.war: > /WEB-INF/ > /WEB-INF/lib/ > /WEB-INF/lib/hsqldb-1.8.0.10.jar > /WEB-INF/web.xml > /WEB-INF/classes/ > /WEB-INF/classes/org/ > /WEB-INF/classes/org/jboss/ > /WEB-INF/classes/org/jboss/wfk/ > /WEB-INF/classes/org/jboss/wfk/test/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/HelloWorldServlet.class > {code} > Stack trace: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:148) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:91) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) > ... 88 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-112) MavenImporter ignores AcceptScopesStrategy for dependency inclusion

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-112?page=com.atlassian.jira.plu... ] Karel Piwko edited comment on SHRINKRES-112 at 3/12/13 4:35 AM: ---------------------------------------------------------------- I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164.... When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes: *Handling transitive dependencies*:: Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following {code} Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call will simply get a dependency, constructs it's tree and get only test scope. This is default behavior for AcceptScopesStrategy - no preFiltering is done Note, that it seems to me that it works only for the first level of dependency tree, might be a *Handling scopes defined in pom*:: Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope> {code} Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>. So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those. You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering. [~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far. The confusion will come from following calls: {code} // prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined) // will fail with no dependencies to be resolved Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); // will grab test scoped dependencies if no pom, because no prefiltering will be applied Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); {code} Any other idea? was (Author: kpiwko): I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164.... When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes: *Handling transitive dependencies*:: Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following {code} Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call will simply get a dependency, constructs it's tree and get only test scope. This is default behavior for AcceptScopesStrategy - no preFiltering is done Note, that it seems to me that it works only for the first level of dependency tree, might be a *Handling scopes defined in pom*:: Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope> {code} Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>. So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those. You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering. [~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far. The confusion will come from following calls: {code} // prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined) // will fail with no dependencies to be resolved Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); // will grap test scoped dependencies if no pom, because no prefiltering will be applied Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); {code} Any other idea? > MavenImporter ignores AcceptScopesStrategy for dependency inclusion > ------------------------------------------------------------------- > > Key: SHRINKRES-112 > URL: https://issues.jboss.org/browse/SHRINKRES-112 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: Karel Piwko > Priority: Blocker > > AcceptScopesStrategy is not correctly propagated: > {code} > @Deployment(testable = false) > public static WebArchive createDeployment() > { > return ShrinkWrap.create(MavenImporter.class) > .loadPomFromFile("pom.xml") > .importBuildOutput(new AcceptScopesStrategy(ScopeType.COMPILE, ScopeType.RUNTIME)) > .as(WebArchive.class); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-112) MavenImporter ignores AcceptScopesStrategy for dependency inclusion

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-112?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-112: --------------------------------------- I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164.... When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes: *Handling transitive dependencies*:: Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following {code} Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call will simply get a dependency, constructs it's tree and get only test scope. This is default behavior for AcceptScopesStrategy - no preFiltering is done Note, that it seems to me that it works only for the first level of dependency tree, might be a *Handling scopes defined in pom*:: Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope> {code} Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles() {code} This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>. So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those. You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering. [~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far. The confusion will come from following calls: {code} // prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined) // will fail with no dependencies to be resolved Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); // will grap test scoped dependencies if no pom, because no prefiltering will be applied Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); {code} Any other idea? > MavenImporter ignores AcceptScopesStrategy for dependency inclusion > ------------------------------------------------------------------- > > Key: SHRINKRES-112 > URL: https://issues.jboss.org/browse/SHRINKRES-112 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: Karel Piwko > Priority: Blocker > > AcceptScopesStrategy is not correctly propagated: > {code} > @Deployment(testable = false) > public static WebArchive createDeployment() > { > return ShrinkWrap.create(MavenImporter.class) > .loadPomFromFile("pom.xml") > .importBuildOutput(new AcceptScopesStrategy(ScopeType.COMPILE, ScopeType.RUNTIME)) > .as(WebArchive.class); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-118) Update ShrinkWrap core to 1.1.2

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-118?page=com.atlassian.jira.plu... ] Andrew Rubinger updated SHRINKRES-118: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.0-beta-3 Resolution: Done Upstream: https://github.com/shrinkwrap/resolver/commit/74fc2fa10fac75db18cac1b77b6... > Update ShrinkWrap core to 1.1.2 > ------------------------------- > > Key: SHRINKRES-118 > URL: https://issues.jboss.org/browse/SHRINKRES-118 > Project: ShrinkWrap Resolvers > Issue Type: Library Upgrade > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 2.0.0-beta-3 > > > SHRINKRES-62 performed shrinkwrap core upgrade from 1.0.0 to 1.1.1. It would be better to upgrade to 1.1.2 which solved critical bug concerning export functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-117) Update Maven to 3.0.5 and Wagon to 2.4

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-117?page=com.atlassian.jira.plu... ] Andrew Rubinger updated SHRINKRES-117: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.0-beta-3 Resolution: Done Upstream: https://github.com/shrinkwrap/resolver/commit/e6675ab6415d71f50bd899cbffe... > Update Maven to 3.0.5 and Wagon to 2.4 > -------------------------------------- > > Key: SHRINKRES-117 > URL: https://issues.jboss.org/browse/SHRINKRES-117 > Project: ShrinkWrap Resolvers > Issue Type: Library Upgrade > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 2.0.0-beta-3 > > > Maven 3.0.5 updated Wagon to 2.4 due to security issues. Those libraries can be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-445) Export of uncompressed ZIP

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-445?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-445: -------------------------------------- Forum Reference: https://community.jboss.org/message/801704#801704 > Export of uncompressed ZIP > -------------------------- > > Key: SHRINKWRAP-445 > URL: https://issues.jboss.org/browse/SHRINKWRAP-445 > Project: ShrinkWrap > Issue Type: Feature Request > Affects Versions: 1.1.2 > Reporter: Michal Matloka > Assignee: Michal Matloka > > https://community.jboss.org/message/801704#801704 suggests: > "Would it be possible to control the compression level in shrinkwrap's ZipExporters implementation? The compression in this use case is unnecessary and slows down the deployment quite a bit." > We have to think, if it should be realised as sepearete UncompressedZipExporter, or to add general configurable compression level option to all compressing exporters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues March 2013