Bug 1104569

Created attachment 902057 [details]
Used settings.xml

Looking from the stacktrace, it can't get the redhat pom.xml from jboss.org.
The log states that "[ERROR] Non-resolvable import POM: Failed to resolve POM for org.jboss.bom:jboss-javaee-6.0-with-tools:1.0.4.Final-redhat-9 due to Could not transfer artifact org.jboss.bom:jboss-javaee-6.0-with-tools:pom:1.0.4.Final-redhat-9 from/to snapshots.jboss.org (http://snapshots.jboss.org/maven2):"

I suspect that this is a maven configuration issues.
I can't produce the same error.

Could you try to copy my_setting.xml to ~/.m2/setting.xml and run:
mvn clean install test -Parq-jbossas-remote

However, I have seen another error:
Running org.jboss.quickstarts.brms.sfksession.HouseFireTest
Jun 05, 2014 2:47:17 PM org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1 call
WARNING: Exception encountered during export of archive
org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/lib/drools-core-6.0.3-redhat-2.jar
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$3.handle(StreamExporterDelegateBase.java:272)
	at org.jboss.shrinkwrap.impl.base.io.IOUtil.closeOnComplete(IOUtil.java:219)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase.processNode(StreamExporterDelegateBase.java:233)
	at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:105)
	at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:109)
	at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:109)
	at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.doExport(AbstractExporterDelegate.java:95)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase.access$001(StreamExporterDelegateBase.java:50)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$1.call(StreamExporterDelegateBase.java:121)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$1.call(StreamExporterDelegateBase.java:116)
	at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:124)
	at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:118)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Pipe closed
	at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:261)
	at java.io.PipedInputStream.receive(PipedInputStream.java:227)
	at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
	at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
	at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)
	at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:314)
	at org.jboss.shrinkwrap.impl.base.io.IOUtil.copy(IOUtil.java:139)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$2.execute(StreamExporterDelegateBase.java:261)
	at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$2.execute(StreamExporterDelegateBase.java:233)
	at org.jboss.shrinkwrap.impl.base.io.IOUtil.closeOnComplete(IOUtil.java:217)
	... 15 more

Jun 05, 2014 2:47:17 PM org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1 call
WARNING: [SHRINKWRAP-120] Possible deadlock scenario: Got exception on closing the ZIP out stream: Pipe closed
java.io.IOException: Pipe closed
	at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:261)
	at java.io.PipedInputStream.receive(PipedInputStream.java:227)
	at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
	at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
	at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:238)
	at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:343)
	at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
	at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:360)
	at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:148)
	at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:118)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 14.358 sec <<< FAILURE!

Results :

Tests in error: 
  org.jboss.quickstarts.brms.sfksession.HouseFireTest: Cannot deploy: test.war

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

The same issue happens to "helloworld-cep".

But I am not sure if this is a serious issues to quickstarts.

(In reply to Tomas David from comment #0)
> Created attachment 902056 [details]
> stacktrace
> 
> Description of problem:
> Quickstarts arquillian tests (helloworld-cep and stateful-ksession) fail
> with exception java.lang.RuntimeException: Could not invoke deployment
> method: public static org.jboss.shrinkwrap.api.Archive
> org.jboss.quickstarts.brms.cep.TransactionsTest.getDeployment(), see
> attachment stacktrace. 
> 
> Version-Release number of selected component (if applicable):
> Quickstarts 6.0.2.ER3
> 
> How reproducible:
> Run tests with my_settings.xml
> 
> Steps to Reproduce:
> 1. Download quickstarts.
> 2. mvn clean install test -Parq-jbossas-remote -s my_settings.xml
> 
> Actual results:
> Arquillian tests fail.
> 
> Expected results:
> Arquillian tests should pass.
> 
> Additional info:

cc Kris for more comments on the  "Cannot deploy: test.war" error.

Noticed that the quickstart run ok followed the instructions. But it failed when run the arquillian tests.

I tried some scenarios:

1. When I have settings.xml in ~/.m2/ then tests pass.

2. When I have settings.xml in ~/.m2/ and settings.xml contains <localRepository>[some location]</localRepository>, then I get same exception as you.

3. Also I tried clean ~/.m2/ folder and run "mvn clean install test -Parq-jbossas-remote -s settings.xml" (settings didn't contain <localRepository>) and tests passed.

...

But I think there is still problem, because not all customers want to replace their settings.xml in ~/.m2/ or clean whole ~/.m2/ directory.

This is because that the setting.xml in command line can't be passed to surfire testcases which use maven in api level instead of CLI in terminal.

Please have a look on https://community.jboss.org/thread/174873 for details explaination.

I think the easiest solution for customer to run the  arquillian tests  is to cp settings.xml to ~/.m2/
Then the testcase will also be able to use the maven setting correctly.

Would it acceptable to add documentation in README.md to guide user to configure the settings.xml ?

(In reply to Tomas David from comment #5)
> I tried some scenarios:
> 
> 1. When I have settings.xml in ~/.m2/ then tests pass.
> 
> 2. When I have settings.xml in ~/.m2/ and settings.xml contains
> <localRepository>[some location]</localRepository>, then I get same
> exception as you.
> 
> 3. Also I tried clean ~/.m2/ folder and run "mvn clean install test
> -Parq-jbossas-remote -s settings.xml" (settings didn't contain
> <localRepository>) and tests passed.
> 
> ...
> 
> But I think there is still problem, because not all customers want to
> replace their settings.xml in ~/.m2/ or clean whole ~/.m2/ directory.

Apologies, but this is not an acceptable solution from the point of view of testing.

Our Jenkins machines use a shared environment, therefore any changes we make to ~/.m2/settings.xml will also affect anyone else who will be using that particular Jenkins machine when we're done with this.

Yep, it's true that we can't just change the ~/.m2/settings.xml in Jenkins and it would break the shared environment.

However after discussed further with Lukas and Tomas in IRC, in this particular cases, the arquilian tests is not really a part of quickstarts itself. It's a unittest for the quickstarts though others quickstarts in jboss-brms-quickstarts are form of unittest. We can't easily fix it for it's a limit of arquilian test itself.

So we decided to ignore to run arquillian test in QE's test code.

Verified.